SERIALIZABLE with parallel query

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: SERIALIZABLE with parallel query
Date: 2016-11-08 21:51:46
Message-ID: CAEepm=0gXGYhtrVDWOTHS8SQQy_=S9xo+8oCxGLWZAOoeJ=yzQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

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.

See attached 5 minute hack. Need to audit predicate.c for cases where
MySerializableXact might be modified without suitable locking, and
probably sprinkle assertions all over the place that workers don't
reach certain places etc. I wonder what horrible things might happen
as a result of workers running with a SERIALIZABLEXACT that contains
the leader's vxid and other such things. I'd love to figure all this
out in time for one of the later CFs in this cycle. Any thoughts?

--
Thomas Munro
http://www.enterprisedb.com

Attachment Content-Type Size
ssi-parallel-hack.patch application/octet-stream 5.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?= 2016-11-08 21:56:43 Re: Re: [PATCH] Tab completion for ALTER TYPE … RENAME VALUE …
Previous Message Robert Haas 2016-11-08 21:32:42 Re: Remove "Source Code" column from \df+ ?