Horton

Re: Custom tuplesorts for extensions

Pavel Borisov <pashkin.elfe@gmail.com>

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

Attachments

I've looked through the updated patch. Overall it looks good enough.

Some minor things:

- PARALLEL_SORT macro is based on coordinate struct instead of state
struct. In some calls(i.e. from _bt_spools_heapscan)  coordinate could
appear to be NULL, which can be a segfault on items dereference inside the
macro.

- state->worker and coordinate->isWorker a little bit differ in semantics
i.e.:
..............................................worker............... leader
state -> worker........................  >=0.....................-1
coordinate ->isWorker............. 1..........................0

- in tuplesort_begin_index_btree I suppose it should be base->nKeys instead
of state->nKeys

- Cfbot reports gcc warnings due to mixed code and declarations. So I used
this to beautify code in tuplesortvariants.c a little. (This is added as a
separate patch 0007)

All these things are corrected/done in a new version 3 of a patchset (PFA).
For me, the patchset seems like a long-needed thing to support PostgreSQL
extensibility. Overall corrections in v3 are minor, so I'd like to mark the
patch as RfC if there are no objections.

-- 
Best regards,
Pavel Borisov
Supabase.

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