From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SERIALIZABLE with parallel query |
Date: | 2017-02-15 13:58:01 |
Message-ID: | CA+Tgmoa43ct2d-JHhexdqrTQ=+w5cZ0=9JL15mjAtAwOVc0sPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 8, 2016 at 4:51 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> Currently we don't generate parallel plans in SERIALIZABLE. What
> problems need to be solved to be able to do that? I'm probably
> steamrolling over a ton of subtleties and assumptions here, but it
> occurred to me that a first step might be something like this:
>
> 1. Hand the leader's SERIALIZABLEXACT to workers.
> 2. Make sure that workers don't release predicate locks.
> 3. Make sure that the leader doesn't release predicate locks until
> after the workers have finished accessing the leader's
> SERIALIZABLEXACT. I think this is already the case.
What happens if the workers exit at the end of the query and the
leader then goes on and executes more queries? Will the
worker-acquired predicate locks be retained or will they go away when
the leader exits?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Kuntal Ghosh | 2017-02-15 14:07:33 | Re: exposing wait events for non-backends (was: Tracking wait event for latches) |
Previous Message | Robert Haas | 2017-02-15 13:48:44 | Re: CREATE TABLE with parallel workers, 10.0? |