Re: Early WIP/PoC for inlining CTEs
От | Andreas Karlsson |
---|---|
Тема | Re: Early WIP/PoC for inlining CTEs |
Дата | |
Msg-id | fc9764f5-cf6f-5e9f-6d30-c64edf399998@proxel.se обсуждение исходный текст |
Ответ на | Re: Early WIP/PoC for inlining CTEs (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | pgsql-hackers |
On 1/1/19 1:42 AM, Andrew Gierth wrote: >>>>>> "Andreas" == Andreas Karlsson <andreas@proxel.se> writes: > > Andreas> I believe I have fixed these except for the comment on the > Andreas> conditions for when we inline. > > Andreas> Andrew Gierth: Why did you chose to not inline on FOR UPDATE > Andreas> but inline volatile functions? I feel that this might be > Andreas> inconsistent since in both cases the query in the CTE can > Andreas> change behavior if the planner pushes a WHERE clause into the > Andreas> subquery, but maybe I am missing something. > > I chose not to inline FOR UPDATE because it was an obvious compatibility > break, potentially changing the set of locked rows, and it was an easy > condition to test. > > I did not test for volatile functions simply because this was a very > early stage of the project (which wasn't my project, I was just > assisting someone else). I left the comment "this likely needs some > additional checks" there for a reason. Thanks, that makes sense! I will need to ponder some on if the behavior change when predicates are pushed into a subquery with volatile functions is ok. I am leaning towards no, because otherwise inlining CTEs would affect more than query performance. Andreas
В списке pgsql-hackers по дате отправления: