On Thu, 21 Apr 2022 at 19:09, John Naylor <john.naylor@enterprisedb.com> wrote:
> I intend to commit David's v2 fix next week, unless there are
> objections, or unless he beats me to it.
I wasn't sure if you wanted to handle it or not, but I don't mind
doing it, so I just pushed it after a small adjustment to a comment.
Before going ahead with it I did test a 2-key sort where the leading
key values were all the same. I wondered if we'd still see any
regression from having to re-compare the leading key all over again.
I just did:
create table ab (a bigint, b bigint);
insert into ab select 0,x from generate_series(1,1000000)x;
vacuum freeze ab;
I then ran:
select * from ab order by a,b offset 1000000;
697492434 (Specialize tuplesort routines for different kinds of
abbreviated keys)
$ pgbench -n -f bench1.sql -T 60 -M prepared postgres
tps = 10.651740 (without initial connection time)
tps = 10.813647 (without initial connection time)
tps = 10.648960 (without initial connection time)
697492434~1 (Remove obsolete comment)
$ pgbench -n -f bench1.sql -T 60 -M prepared postgres
tps = 9.957163 (without initial connection time)
tps = 10.191168 (without initial connection time)
tps = 10.145281 (without initial connection time)
So it seems there was no regression for that case, at least, not on
the AMD machine that I tested on.
David
