On Thu, 21 Apr 2022 at 19:09, John Naylor <john.nay...@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
