Re: Avoid computing ORDER BY junk columns unnecessarily

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: Avoid computing ORDER BY junk columns unnecessarily
Дата
Msg-id CAMbWs48z9NqdwL6LnQZwnV8RR=BKEpXyDLoYaj5RzFOMvFheaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoid computing ORDER BY junk columns unnecessarily  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On Sat, Dec 23, 2023 at 1:32 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 22/12/2023 17:24, Tom Lane wrote:
>> How much of your patchset still makes sense if we assume that we
>> can always extract the ORDER BY column values from the index?

> That would make it much less interesting. But I don't think that's a
> good assumption. Especially in the kNN case, the ORDER BY value would
> not be stored in the index. Most likely the index needs to calculate it
> in some form, but it might take shortcuts like avoiding the sqrt().

Yeah, fair point.  I'll try to take a look at your patchset after
the holidays.

Agreed.

I haven't looked into these patches, but it seems that there is an issue
with how the targetlist is handled for foreign rels.  The following test
case for postgres_fdw hits the Assert in apply_tlist_labeling().

contrib_regression=# SELECT c3, c4 FROM ft1 ORDER BY c3, c1 LIMIT 1;
server closed the connection unexpectedly

When we create foreign final path in add_foreign_final_paths(), we use
root->upper_targets[UPPERREL_FINAL] as the PathTarget.  This PathTarget
is set in grouping_planner(), without removing the junk columns.  I
think this is why the above query hits the Assert.

Thanks
Richard

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

Предыдущее
От: Junwang Zhao
Дата:
Сообщение: Re: Proposal to include --exclude-extension Flag in pg_dump
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Optimization outcome depends on the index order