From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Custom tuplesorts for extensions |
Date: | 2022-07-24 12:24:42 |
Message-ID: | CAPpHfdu5oW1U-sC+SsBS=vTxNG7d-2GS-BmPdwE-xhfvygtVwQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, Pavel!
Thank you for your review and corrections.
On Fri, Jul 22, 2022 at 6:57 PM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
0001-Remove-Tuplesortstate.copytup-function-v4.patch | application/octet-stream | 16.7 KB |
0004-Move-memory-management-away-from-writetup-and-tup-v4.patch | application/octet-stream | 8.2 KB |
0002-Add-new-Tuplesortstate.removeabbrev-function-v4.patch | application/octet-stream | 10.4 KB |
0005-Split-TuplesortPublic-from-Tuplesortstate-v4.patch | application/octet-stream | 69.6 KB |
0003-Put-abbreviation-logic-into-puttuple_common-v4.patch | application/octet-stream | 10.7 KB |
0006-Split-tuplesortvariants.c-from-tuplesort.c-v4.patch | application/octet-stream | 116.9 KB |
tuplesort_patch_test.zip | application/zip | 102.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Yura Sokolov | 2022-07-24 12:26:12 | Re: optimize lookups in snapshot [sub]xip arrays |
Previous Message | Julien Rouhaud | 2022-07-24 11:44:49 | Re: redacting password in SQL statement in server log |