Re: Use virtual tuple slot for Unique node - Mailing list pgsql-hackers

From David Rowley
Subject Re: Use virtual tuple slot for Unique node
Date
Msg-id CAApHDvqMKvKFhfaNGPG_d0hxaHpozYidPt+NQiEO55Ba_kf5og@mail.gmail.com
Whole thread Raw
In response to Re: Use virtual tuple slot for Unique node  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Use virtual tuple slot for Unique node
List pgsql-hackers
On Thu, 12 Oct 2023 at 23:06, Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> Q7 select distinct a,b from (select string_agg(left(a, 100), ', ')
> over (order by a rows 2 preceding) a, b from t_text) q
> HEAD: 16070.62 ms
> patched: 16182.16 ms

Did you time the SELECT or EXPLAIN ANALYZE?

With SELECT, I'm unable to recreate this slowdown. Using your setup:

$ cat bench.sql
set enable_hashagg=0;
set work_mem='10GB';
select distinct a,b from (select string_agg(left(a, 100), ', ') over
(order by a rows 2 preceding) a, b from t_text) q;

Master @ 13d00729d
$ pgbench -n -f bench.sql -T 300 postgres | grep latency
latency average = 7739.250 ms

Master + use_subnode_slot_type_for_nodeunique.patch
$ pgbench -n -f bench.sql -T 300 postgres | grep latency
latency average = 7718.007 ms

It's hard to imagine why there would be a slowdown as this query uses
a TTSOpsMinimalTuple slot type in the patch and the unpatched version.

David



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [PoC] pg_upgrade: allow to upgrade publisher node
Next
From: Michael Banck
Date:
Subject: [patch] pg_basebackup: mention that spread checkpoints are the default in --help