Re: Custom tuplesorts for extensions
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Pavel Borisov <pashkin.elfe@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-24T12:24:42Z
Lists: pgsql-hackers
Attachments
- 0001-Remove-Tuplesortstate.copytup-function-v4.patch (application/octet-stream) patch v4-0001
- 0004-Move-memory-management-away-from-writetup-and-tup-v4.patch (application/octet-stream) patch v4-0004
- 0002-Add-new-Tuplesortstate.removeabbrev-function-v4.patch (application/octet-stream) patch v4-0002
- 0005-Split-TuplesortPublic-from-Tuplesortstate-v4.patch (application/octet-stream) patch v4-0005
- 0003-Put-abbreviation-logic-into-puttuple_common-v4.patch (application/octet-stream) patch v4-0003
- 0006-Split-tuplesortvariants.c-from-tuplesort.c-v4.patch (application/octet-stream) patch v4-0006
- tuplesort_patch_test.zip (application/zip)
Hi, Pavel! Thank you for your review and corrections. On Fri, Jul 22, 2022 at 6:57 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote: > 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 Perfect, thank you! > - 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) It appears that warnings were caused by the extra semicolon in TuplesortstateGetPublic() macro. I've removed that semicolon, and I don't think we need a beautification patch. Also, please note that there is no point to add indentation, which doesn't survive pgindent. > 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. Thank you. I've also revised the comments in the top of tuplesort.c and tuplesortvariants.c. The revised patchset is attached. Also, my OrioleDB colleagues Ilya Kobets and Tatsiana Yaumenenka run tests to check if the patchset causes a performance regression. The script and results are present in the "tuplesort_patch_test.zip" archive. The final comparison is given in the result/final_table.txt. In short, they repeat each test 10 times and there is no difference exceeding the random variation. ------ Regards, Alexander Korotkov
Commits
-
Split tuplesortvariants.c from tuplesort.c
- d0b193c0fad1 16.0 landed
-
Split TuplesortPublic from Tuplesortstate
- ec92fe98356a 16.0 landed
-
Move memory management away from writetup() and tuplesort_put*()
- 097366c45f5d 16.0 landed
-
Put abbreviation logic into puttuple_common()
- 033dd02db224 16.0 landed
-
Add new Tuplesortstate.removeabbrev function
- cadfdd1edff1 16.0 landed
-
Remove Tuplesortstate.copytup function
- d47da3162b4d 16.0 landed