Horton

Re: Custom tuplesorts for extensions

John Naylor <john.naylor@enterprisedb.com>

View thread View on postgr.es
From: John Naylor <john.naylor@enterprisedb.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, Maxim Orlov <orlovmg@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-07-21T03:44:26Z
Lists: pgsql-hackers

Attachments

On Tue, Jul 12, 2022 at 3:23 PM Alexander Korotkov <aekorotkov@gmail.com>
wrote:
> There are some places, which potentially could cause a slowdown.  I'm
> going to make some experiments with that.

I haven't looked at the patches, so I don't know of a specific place to
look for a slowdown, but I thought it might help to perform the same query
tests as my most recent test for evaluating qsort variants (some
description in [1]), and here is the spreadsheet. Overall, the differences
look like noise. A few cases with unabbreviatable text look a bit faster
with the patch. I'm not sure if that's a real difference, but in any case I
don't see a slowdown anywhere.

[1]
https://www.postgresql.org/message-id/CAFBsxsHeTACMP1JVQ%2Bm35-v2NkmEqsJMHLhEfWk4sTB5aw_jkQ%40mail.gmail.com
--
John Naylor
EDB: http://www.enterprisedb.com

Commits

  1. Split tuplesortvariants.c from tuplesort.c

  2. Split TuplesortPublic from Tuplesortstate

  3. Move memory management away from writetup() and tuplesort_put*()

  4. Put abbreviation logic into puttuple_common()

  5. Add new Tuplesortstate.removeabbrev function

  6. Remove Tuplesortstate.copytup function