Re: A qsort template

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A qsort template
Date: 2021-06-29 06:56:07
Message-ID: CA+hUKGLPommgNw-SVwUGkw1YmTDwmJ5vSKO0kFnZfbRHtNFW5w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 29, 2021 at 1:11 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> I spotted a mistake in v3: I didn't rename ST_COMPARE_TYPE to
> ST_COMPARE_RET_TYPE in the 0009 patch (well, I did, but forgot to
> commit before I ran git format-patch). I won't send another tarball
> just for that, but will correct it next time.

Here's a version that includes a rather hackish test module that you
might find useful to explore various weird effects. Testing sorting
routines is really hard, of course... there's a zillion parameters and
things you could do in the data and cache effects etc etc. One of the
main things that jumps out pretty clearly though with these simple
tests is that sorting 6 byte ItemPointerData objects is *really slow*
compared to more natural object sizes (look at the times and the
MEMORY values in the scripts). Another is that specialised sort
functions are much faster than traditional qsort (being one of the
goals of this exercise). Sadly, the 64 bit comparison technique is
not looking too good in the output of this test.

Attachment Content-Type Size
more-sort-search-specializations-v4.tgz application/x-compressed-tar 16.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-06-29 06:56:11 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Andrey Borodin 2021-06-29 06:48:05 Re: Synchronous commit behavior during network outage