Re: Refactoring IndexPath representation of index conditions

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Refactoring IndexPath representation of index conditions
Дата
Msg-id 20190202200232.l5mdufc7leiihgxs@alap3.anarazel.de
обсуждение исходный текст
Ответ на Refactoring IndexPath representation of index conditions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Refactoring IndexPath representation of index conditions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-02-02 11:29:10 -0500, Tom Lane wrote:
> I think that the original idea here was that we should do as little
> work as possible "up front", since most index paths will get discarded
> before we reach createplan.c.  But to the extent that that was valid
> at all, it's gotten overtaken by circumstances.  In particular,
> postponing work to expand_indexqual_conditions (which is called by
> create_index_path) is just stupid, because these days we typically
> call that several times with the same index conditions.  It's really
> dubious that postponing commutation to createplan.c is a net win either,

It seems your approach isn't particularly in contradiction to the
stated historical goal. We could create the new struct, but just not
populate it eagerly, right?



> Thoughts?  If there's not objections I'd like to push this soon.

Seems reasonable from a very very quick skim.

Andres


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Early WIP/PoC for inlining CTEs
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Ryu floating point output patch