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 |
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 |