Re: [HACKERS] pg_background contrib module proposal - Mailing list pgsql-hackers

From Andrew Borodin
Subject Re: [HACKERS] pg_background contrib module proposal
Date
Msg-id CAJEAwVFQ6UeVCLcFv8CLGeuqh1yweC3xvvn12P2uLEGcz5-bFQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_background contrib module proposal  (Andrew Borodin <borodin@octonica.com>)
Responses Re: [HACKERS] pg_background contrib module proposal  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] pg_background contrib module proposal  (amul sul <sulamul@gmail.com>)
Re: [HACKERS] pg_background contrib module proposal  (David Fetter <david@fetter.org>)
List pgsql-hackers
Hi!

Just in case you'd like to include sleepsort as a test, here it is
wrapped as a regression test(see attachment). But it has serious
downside: it runs no less than 5 seconds.

Also I'll list here every parallelism feature I managed to imagine. It
is not to say that I suggest having some of these features at v1. We
certainly have to start somewhere, this list is just for information
purposes.
1. Poolable workers. Just to be sure you can reliably queue your task
somewhere without having "increase max_connections" hint.
2. Inside one pool, you can have task chaining. After competition of
task A (query A) start task B, in case of failure start task C. Task C
is followed by task D.
3. Reliably read task status: running\awaiting\completed\errored\in a
lock. Get a query plan of a task? (I know, there are reasons why it is
not possible now)
4. Query as a future (actually it is implemented already by
pg_background_result)
5. Promised result. Declare that you are waiting for data of specific
format, execute a query, someone (from another backend) will
eventually place a data to promised result and your query continues
execution.
6. Cancelation: a way to signal to background query that it's time to
quit gracefully.

Best regards, Andrey Borodin.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Nested Wait Events?
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument