Re: Use virtual tuple slot for Unique node

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Денис Смирнов <darthunix(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Use virtual tuple slot for Unique node
Date: 2023-10-10 08:48:51
Message-ID: CAApHDvr358MErpm-5_jEsCfVDFpuPhN=8_xPbtAfAbqSs7HXsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 27 Sept 2023 at 20:01, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Sat, 23 Sept 2023 at 03:15, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > So not a win in this case. Could you peek at the outer slot type, and
> > use the same kind of slot for the Unique's result? Or some more
> > complicated logic, like use a virtual slot if all the values are
> > pass-by-val? I'd also like to keep this simple, though...
> >
> > Would this kind of optimization make sense elsewhere?
>
> There are a few usages of ExecGetResultSlotOps(). e.g ExecInitHashJoin().
>
> If I adjust the patch to:
>
> - ExecInitResultTupleSlotTL(&uniquestate->ps, &TTSOpsMinimalTuple);
> + ExecInitResultTupleSlotTL(&uniquestate->ps,
> +
> ExecGetResultSlotOps(outerPlanState(uniquestate),
> +
> NULL));

Just to keep this from going cold, here's that in patch form for
anyone who wants to test.

I spent a bit more time running some more benchmarks and I don't see
any workload where it slows things down. I'd be happy if someone else
had a go at finding a regression.

David

Attachment Content-Type Size
use_subnode_slot_type_for_nodeunique.patch text/plain 1.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Esteban Zimanyi 2023-10-10 08:58:57 Fwd: Advice about preloaded libraries
Previous Message Richard Guo 2023-10-10 08:32:55 Re: Check each of base restriction clauses for constant-FALSE-or-NULL