Re: Insertion Sort Improvements

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Benjamin Coutu <ben(dot)coutu(at)zeyos(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Insertion Sort Improvements
Date: 2022-09-28 03:31:33
Message-ID: CAFBsxsFs5=0yHx+-03EYkf+Y_s0evkgDYstUXFeQvogTi7dSig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 27, 2022 at 4:39 PM Benjamin Coutu <ben(dot)coutu(at)zeyos(dot)com> wrote:
>
> Getting back to improvements for small sort runs, it might make sense to
consider using in-register based sorting via sorting networks for very
small runs.

> It looks like some of the commercial DBMSs do this very successfully.

"Looks like"?

> They use 4 512bit registers (AVX-512) in this example, which could
technically store 4 * 4 sort-elements (given that the sorting key is 64 bit
and the tuple pointer is 64 bit). I wonder whether this could also be done
with just SSE (instead of AVX), which the project now readily supports
thanks to your recent efforts?

SortTuples are currently 24 bytes, and supported vector registers are 16
bytes, so not sure how you think that would work.

More broadly, the more invasive a change is, the more risk is involved, and
the more effort to test and evaluate. If you're serious about trying to
improve insertion sort performance, the simple idea we discussed at the
start of the thread is a much more modest step that has a good chance of
justifying the time put into it. That is not to say it's easy, however,
because testing is a non-trivial amount of work.

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2022-09-28 03:49:07 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Amit Kapila 2022-09-28 03:28:56 Re: A doubt about a newly added errdetail