Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
Дата
Msg-id 2732256.1657163219@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-bugs
David Rowley <dgrowleyml@gmail.com> writes:
> I've been looking for a good excuse to commit Andy's NOT NULL patch so
> that he has some more foundations for the other work he's doing.  This
> might be that excuse.

> Does anyone think differently?

While I don't have any problem with tracking column NOT NULL flags
in RelOptInfo once the planner has a use for that info, I'm not sure
that we have a solid use-case for it quite yet.  In particular, the
fact that the table column is marked NOT NULL doesn't mean that any
particular occurrence of that column's Var can be freely assumed to be
non-null.  The patch I'm working on to label Vars that have possibly
been nulled by outer joins [1] seems like essential infrastructure for
doing anything very useful with the info.

Maybe that objection doesn't apply to build_minmax_path's usage in
particular, but that's an awfully narrow use-case.

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/830269.1656693747@sss.pgh.pa.us



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower