| From: | Serge Rielau <serge(at)rielau(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>, Ilya Shkuratov <motr(dot)ilya(at)ya(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Mario Becroft <mb(at)true(dot)group> |
| Subject: | Re: CTE inlining |
| Date: | 2017-05-04 18:59:32 |
| Message-ID: | aec1bf28-ded4-4b92-9bd4-6af1f21e394e@rielau.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I haven't been keeping close tabs either, but surely we still have to have
the optimization fence in (at least) all these cases:
* CTE contains INSERT/UPDATE/DELETE
* CTE contains SELECT FOR UPDATE/SHARE (else the set of rows that get
locked might change)
* CTE contains volatile functions
I'm willing to write off cases where, eg, a function should have been
marked volatile and was not. That's user error and there are plenty
of hazards of that kind already. But if the optimizer has reason
to know that discarding the fence might change any query side-effects,
it mustn't. Yes! +100
Cheers Serge
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-05-04 19:14:45 | Re: json_agg produces nonstandard json |
| Previous Message | Robert Haas | 2017-05-04 18:52:34 | Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling) |