Re: Does TupleQueueReaderNext() really need to copy its result?

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Does TupleQueueReaderNext() really need to copy its result?
Дата
Msg-id CA+hUKGKbLHyezadPh2F+cRpG+cvm0O0vd9nq-RcPQKfW41dh6w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Does TupleQueueReaderNext() really need to copy its result?  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Does TupleQueueReaderNext() really need to copy its result?  (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>)
Список pgsql-hackers
On Thu, May 14, 2020 at 10:55 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Tue, Aug 27, 2019 at 6:35 AM Andres Freund <andres@anarazel.de> wrote:
> > Perhaps this'd could be sidestepped by funneling through MinimalTuples
> > instead of HeapTuples. Afaict that should always be sufficient, because
> > all system column accesses ought to happen below (including being
> > projected into a separate column, if needed above). With the added
> > benefit of needing less space, of course.

Right, create_gather[_merge]_plan() does create_plan_recurse(...,
CP_EXACT_TLIST).  Here's a new version that updates the comment there
to note that this is not merely a good idea but a requirement, due to
the MinimalTuple conveyance.  (I think there may be another reason the
system columns are projected away even without that, but saying so
explicitly and documenting it seems useful either way).

> I tried that out (attached).  That makes various simple tests like
> this to go 10%+ faster on my development machine:

I registered this patch as https://commitfest.postgresql.org/28/2560/
in case someone would like to review it.

Вложения

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

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Review for GetWALAvailability()