From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SERIALIZABLE with parallel query |
Date: | 2017-06-27 23:21:38 |
Message-ID: | CAEepm=2VJvNC7AUJMd6Dus0wL9msTFyrAH0umsWkDvwZf4jp+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 4, 2017 at 8:25 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> ... but considering that these data structures may
> finish up being redesigned as part of the GSoC project[1], it may be
> best to wait and see where that goes before doing anything. I'll
> follow developments there, and if this patch remains relevant I'll
> plan to do some more work on it including testing (possibly with the
> RUBiS benchmark from Kevin and Dan's paper since it seems the most
> likely to be able to really use parallelism) for PG11 CF1.
I've been keeping one eye on the GSoC project. That patch changes the
inConflicts and outConflicts data structures, but not the locking
protocol. This patch works by introducing per-SERIALIZABLEXACT
locking in the places where the code currently assumes that the
current backend is the only one that could modify a shared data
structure (namely MySerializableXact->predicateLocks), so that
MySerializableXact can be shared with workers. There doesn't seem to
be any incompatibility or dependency so far, so here's a rebased
patch. Testing needed.
--
Thomas Munro
http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
ssi-parallel-v5.patch | application/octet-stream | 18.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2017-06-27 23:45:31 | Re: transition table behavior with inheritance appears broken |
Previous Message | Andres Freund | 2017-06-27 21:13:28 | Re: Fast promotion not used when doing a recovery_target PITR restore? |