Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental) |
Дата | |
Msg-id | CA+Tgmoago7XK2SdwdVTZAMc4z1vhYfT4SSVwMMrJScCSPVR9cA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental) (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
|
Список | pgsql-hackers |
On Wed, Nov 1, 2017 at 3:47 AM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > But maybe there's a simpler option - what if we only allow fetches from > the PARALLEL cursor while the cursor is open? That is, this would work: > > BEGIN; > ... > DECLARE x PARALLEL CURSOR FOR SELECT * FROM t2 WHERE ...; > FETCH 1000 FROM x; > FETCH 1000 FROM x; > FETCH 1000 FROM x; > CLOSE x; > ... > COMMIT; > > but adding any other command between the OPEN/CLOSE commands would fail. > That should close all the holes with parallel-unsafe stuff, right? I think that still leaves a fair number of scenarios to consider, and the error handling by itself seems pretty thorny. Plus it's kind of a weird mode and, like Craig, I'm not really sure what it gets you. Maybe if somebody has the use case where this would help, they should just do: CREATE TEMP TABLE x AS SELECT * FROM t2 WHERE ...; DECLARE x CURSOR FOR SELECT * FROM x; Since e9baa5e9fa147e00a2466ab2c40eb99c8a700824, that ought to work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: