From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Денис Смирнов <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-19 09:29:17 |
Message-ID: | CAApHDvqMKvKFhfaNGPG_d0hxaHpozYidPt+NQiEO55Ba_kf5og@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 12 Oct 2023 at 23:06, Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Banck | 2023-10-19 09:39:32 | [patch] pg_basebackup: mention that spread checkpoints are the default in --help |
Previous Message | Hayato Kuroda (Fujitsu) | 2023-10-19 09:24:04 | RE: [PoC] pg_upgrade: allow to upgrade publisher node |