From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Parallel query execution with SPI |
Date: | 2017-03-31 13:18:47 |
Message-ID: | 05930e35-9034-e55c-fbd4-33f92bee3704@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31.03.2017 13:48, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 3:33 AM, Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>> It is possible to execute query concurrently using SPI?
>> If so, how it can be enforced?
>> I tried to open cursor with CURSOR_OPT_PARALLEL_OK flag but it doesn't help:
>> query is executed by single backend while the same query been launched at
>> top level uses parallel plan:
>>
>> fsstate->portal = SPI_cursor_open_with_args(NULL, fsstate->query,
>> fsstate->numParams, argtypes, values, nulls, true, CURSOR_OPT_PARALLEL_OK);
>> ...
>> SPI_cursor_fetch(fsstate->portal, true, 1);
> Parallel execution isn't possible if you are using a cursor-type
> interface, because a parallel query can't be suspended and resumed
> like a non-parallel query. If you use a function that executes the
> query to completion in one go, like SPI_execute_plan, then it's cool.
> See also commit 61c2e1a95f94bb904953a6281ce17a18ac38ee6d.
>
Thank you very much for explanation.
In case of using SPI_execute the query is really executed concurrently.
But it means that when I am executing some query using SPI, I need to
somehow predict number of returned tuples.
If it is not so much, then it is better to use SPI_execute to allow
concurrent execution of the query.
But if it is large enough, then SPI_execute without limit can cause
memory overflow.
Certainly I can specify some reasonable limit and it if is reached, then
use cursor instead.
But it is neither convenient, neither efficient.
I wonder if somebody can suggest better solution?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-03-31 13:20:33 | Re: strange parallel query behavior after OOM crashes |
Previous Message | Robert Haas | 2017-03-31 13:17:46 | Re: Patch: Write Amplification Reduction Method (WARM) |