Re: A qsort template
| От | David Rowley |
|---|---|
| Тема | Re: A qsort template |
| Дата | |
| Msg-id | CAApHDvr8bhkgsdOxhUUngX5n72UkJ6NTjprSGthX_CX1KWxZPg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: A qsort template (John Naylor <john.naylor@enterprisedb.com>) |
| Ответы |
Re: A qsort template
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: