Re: Does TupleQueueReaderNext() really need to copy its result? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Does TupleQueueReaderNext() really need to copy its result?
Date
Msg-id CA+hUKGKbLHyezadPh2F+cRpG+cvm0O0vd9nq-RcPQKfW41dh6w@mail.gmail.com
Whole thread Raw
In response to Re: Does TupleQueueReaderNext() really need to copy its result?  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Does TupleQueueReaderNext() really need to copy its result?  (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>)
List 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.

Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Review for GetWALAvailability()