Re: BUG #17721: A completely unused CTE negatively affect Query Plan

Поиск
Список
Период
Сортировка
От Nathaniel Hazelton
Тема Re: BUG #17721: A completely unused CTE negatively affect Query Plan
Дата
Msg-id 8172A34A-A318-49B4-86D4-5557AFEF8AA1@sturdyai.com
обсуждение исходный текст
Ответ на Re: BUG #17721: A completely unused CTE negatively affect Query Plan  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-bugs


On 12/14/22, 10:46 PM, "David Rowley" <dgrowleyml@gmail.com <mailto:dgrowleyml@gmail.com>> wrote:

On Thu, 15 Dec 2022 at 11:47, Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:
>
> Nathaniel Hazelton <nathaniel@sturdyai.com <mailto:nathaniel@sturdyai.com>> writes:
> > The CTE in that location was emulating a view in which we have a CTE -
> > which responds the same way. Does this mean CTEs can never be used in
> > views that could be flattened without affecting performance?
>
> You've got a view with an unused CTE? Why?


hmm, but the CTE isn't unused. It's just that we don't push quals
down due to the "materialized". Perhaps the view only contains the
CTE? Strange way to write a view... Perhaps there was some reason to
materialise it that's not obvious to us.

NH: Oops.  I posted a slightly incorrect version of what I was trying to show.  Remove the 'materialized', and it acts
thesame way.  Given that it selects 1/0, it's clearly not executed, materialized or not.  BUT it does affect the query
plan,materialized OR NOT, which is the part I couldn't understand.  We do not have an unused CTE in our view.  I was
justattempting to boil what I saw as a bug down to its minimal example.
 


> But at any rate, yes, the presence of a CTE is an optimization
> fence: we can't flatten the subquery containing it without losing
> the query level at which the CTE should be evaluated. Perhaps there
> are special cases where that could be relaxed, but nobody's tried
> very hard.


Just to expand on that a little. Prior to v12, CTEs could never have
quals pushed down into them. That was relaxed in v12 and the original
behaviour can be obtained using "materialized". Without that, the
planner is more free to perform its typical optimisations such as
pulling up subqueries or pushing quals down into subqueries.

NH;  We do use a non-materialized CTE in the view, because we want to use a CTE for what it's for - organizing our
code. Given that it's not materialized, we thought there should be no ill effect.  Remove the materialized from the
originalpost, and you will see it DOES affect the query plan.
 

NH: I will post a more complete example with views today.

Nathaniel




В списке pgsql-bugs по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'
Следующее
От: reiner peterke
Дата:
Сообщение: Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'