From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental) |
Date: | 2018-01-17 13:53:47 |
Message-ID: | CANP8+jJoAitOY5uM6L8xYjPHK-RjJtmsZ5TZKGrH8m54U9sfzA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17 October 2017 at 14:16, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Oct 14, 2017 at 2:14 PM, Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> I propose is to add a new cursor option (PARALLEL), which would allow
>> parallel plans for that particular user-defined cursor. Attached is an
>> experimental patch doing this (I'm sure there are some loose ends).
>
> I think you would need to do a huge amount of additional work in order
> to actually make this robust. I believe that a fair amount of what
> goes on in parallel mode right now is checked with elog() if we think
> that it's unreachable without writing C code -- but this will make a
> lot of those things reachable, which means they would need to be
> checked some other way. Also, I doubt this guarantees that we won't
> try to call parallel-unsafe functions will parallel mode is active, so
> things will just blow up in whatever way they do, maybe crashing the
> server or rendering the database inconsistent or whatever.
>
> Possibly I'm overestimating the extent of the danger, but I don't
> think so. You're try to take a mechanism that was only ever meant to
> be active during the course of one query and applying it for long
> periods of time during which a user can do anything, with basically no
> upgrade of the infrastructure. I think something like this could be
> made to work if you put a large amount of energy into it, but I think
> the patch as proposed is about the easiest 3-5% of what would actually
> be required to cover all the holes.
Maybe so.
At present, one major use of Cursors is in postgres_fdw.
In that usage, the query executes and returns all the rows. No other
side execution is possible.
How do we make parallel query work for Cursors, if not by Tomas' proposal?
What more restrictive proposal would you prefer?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2018-01-17 13:58:45 | Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental) |
Previous Message | Peter Eisentraut | 2018-01-17 13:51:57 | Re: pg_(total_)relation_size and partitioned tables |