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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Does TupleQueueReaderNext() really need to copy its result?
Date: 2020-06-17 04:47:23
Message-ID: CA+hUKGKbLHyezadPh2F+cRpG+cvm0O0vd9nq-RcPQKfW41dh6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 14, 2020 at 10:55 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Tue, Aug 27, 2019 at 6:35 AM Andres Freund <andres(at)anarazel(dot)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 Content-Type Size
v2-0001-Use-MinimalTuple-for-tuple-queues.patch text/x-patch 11.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-06-17 04:56:07 Re: Review for GetWALAvailability()
Previous Message Dilip Kumar 2020-06-17 04:39:33 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions