Re: Custom tuplesorts for extensions - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: Custom tuplesorts for extensions
Date
Msg-id CALT9ZEEb_rqGNHy8weVkEuZ2NnqwGx17-bOZ5tdPL=1bvTa80Q@mail.gmail.com
Whole thread Raw
In response to Re: Custom tuplesorts for extensions  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Custom tuplesorts for extensions
List pgsql-hackers
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.
Attachment

pgsql-hackers by date:

Previous
From: Anthony Sotolongo
Date:
Subject: Re: Expose Parallelism counters planned/execute in pg_stat_statements
Next
From: Julien Rouhaud
Date:
Subject: Re: Expose Parallelism counters planned/execute in pg_stat_statements