Re: Custom tuplesorts for extensions

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

In response to

Responses

Browse pgsql-hackers by date

  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