Re: Asynchronous execution support for Custom Scan

From: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
To: Kazutaka Onishi <onishi(at)heterodb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Kohei KaiGai <kaigai(at)heterodb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Subject: Re: Asynchronous execution support for Custom Scan
Date: 2022-11-22 09:07:27
Message-ID: 7453168.EvYhyI6sBW@aivenlaptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Le mardi 6 septembre 2022, 11:29:55 CET Etsuro Fujita a écrit :
> On Mon, Sep 5, 2022 at 10:32 PM Kazutaka Onishi <onishi(at)heterodb(dot)com> wrote:
> > I'm sorry for my error on your name...
>
> No problem.
>
> > > IIUC, it uses the proposed
> > >
> > > APIs, but actually executes ctidscans *synchronously*, so it does not
> > > improve performance. Right?
> >
> > Exactly.
> > The actual CustomScan that supports asynchronous execution will
> > start processing in CustomScanAsyncRequest,
> > configure to detect completion via file descriptor in
> > CustomScanAsyncConfigureWait,
> > and receive the result in CustomScanAsyncNotify.
>
> Ok, thanks!

Thanks for this patch, seems like a useful addition to the CustomScan API.
Just to nitpick: there are extraneous tabs in createplan.c on a blank line.

Sorry for the digression, but I know your ctidscan module had been proposed
for inclusion in contrib a long time ago, and I wonder if the rationale for
not including it could have changed. We still don't have tests which cover
CustomScan, and I can think of at least a few use cases where this customscan
is helpful and not merely testing code.

One of those use case is when performing migrations on a table, and one wants
to update the whole table by filling a new column with a computed value. You
obviously don't want to do it in a single transaction, so you end up batching
updates using an index looking for null values. If you want to do this, it's
much faster to update rows in a range of block, performing a first series of
batch updating all such block ranges, and then finally update the ones we
missed transactionally (inserted in a block we already processed while in the
middle of the batch, or in new blocks resulting from a relation extension).

Best regards,

--
Ronan Dunklau

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii.Yuki@df.MitsubishiElectric.co.jp 2022-11-22 09:11:13 RE: [CAUTION!! freemail] Re: Partial aggregates pushdown
Previous Message Aleksander Alekseev 2022-11-22 09:00:57 Re: Add 64-bit XIDs into PostgreSQL 15