Re: Asynchronous MergeAppend - Mailing list pgsql-hackers

From Matheus Alcantara
Subject Re: Asynchronous MergeAppend
Date
Msg-id DF0RCOYB19RC.35BW2FHPO4N4S@gmail.com
Whole thread Raw
In response to Re: Asynchronous MergeAppend  (Alexander Pyhalov <a.pyhalov@postgrespro.ru>)
Responses Re: Asynchronous MergeAppend
List pgsql-hackers
Thanks for the new version. I don't have other comments on the current
state of the patch. It seems to working as expected and we have
performance improvements that I think that it make it worthwhile.

I have just a small comment on 0002:

+    noccurred = WaitEventSetWait(node->ms_eventset, -1 /* no timeout */ , occurred_event,
+                                 nevents, WAIT_EVENT_APPEND_READY);

Should we use the same WAIT_EVENT_APPEND_READY or create a new wait
event for merge append?

I've spent some time thinking about how we could remove some parts of
the duplicated code that you've previously mention. I think that we
could try to create something like we already have for relation scan
operations, that we have execScan.c that is used for example by
nodeSeqScan.c and nodeIndexScan.c. The attached patch 0003 is a draft
that I attempt to implement this idea. The 0001 and 0002 remains the
same as the previous version. The 0003 was build on top of these.

I've created Appender and AppenderState types that are used by
Append/MergeAppend and AppendState/MergeAppendState respectively (I
should have think in a better name for these base type, ideas are
welcome). The execAppend.c was created to have the functions that can be
reused by Append and MergeAppend execution. I've tried to remove
duplicated code blocks that was almost the same and that didn't require
much refactoring.

I think that there still more opportunities to remove similar code
blocks that for example are on ExecMergeAppendAsyncGetNext and
ExecAppendAsyncGetNext but it require refactoring.

Thoughts?

--
Matheus Alcantara
EDB: http://www.enterprisedb.com


Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: index prefetching
Next
From: Heikki Linnakangas
Date:
Subject: Re: Visibility bug in tuple lock