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 CAJEAwVEpKtTeR6oG=8=Lvbb6BVqoepMK5iH=9iuM6sEB-YCnFQ@mail.gmail.com
Whole thread Raw
In response to pg_background contrib module proposal  (amul sul <sulamul@gmail.com>)
Responses Re: [HACKERS] pg_background contrib module proposal
List pgsql-hackers
2016-12-21 4:55 GMT+05:00 David Fetter <david@fetter.org>:
> I see.
>
> I find the following a little easier to follow, and the sleeps still
> work even when very short.

Now I know a little more SQL :) Thank you.

I'm not sure every platform supports microsecond sleeps. But it will
work anyway. This test is deterministic.
Without sequence here is no race condition. So it is not sleepsort, it
is deterministic. Though I agree that it is good thing for test, I'd
still add some miliseconds to test case when main query for sure have
to wait end of other sleeping query.
.
>
> CREATE TABLE input AS
> SELECT x, row_number() OVER (ORDER BY x) n
> FROM
>     generate_series(0,.000005,0.000001) x
>     ORDER BY x DESC;
>
> CREATE TABLE output(place int,value float);
>
> CREATE TABLE handles AS
> SELECT pg_background_launch(
>     format($$
>         SELECT pg_sleep(%s);
>         INSERT INTO output VALUES (%s, %s)
>         $$,
>         x, n, x
>     )
> ) h
> FROM input;
>
> --wait until everyone finishes
> SELECT * FROM handles JOIN LATERAL pg_background_result(handles.h) AS (x TEXT) ON (true);
>
> --output results
> SELECT * FROM output ORDER BY place;

Best regrards, Andrey Borodin.



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [HACKERS] bigint vs txid user confusion
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Logical decoding on standby