From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Joshua Chamberlain <josh(at)zephyri(dot)co>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE TABLE with parallel workers, 10.0? |
Date: | 2017-02-16 01:13:13 |
Message-ID: | 20170216011313.tsz344sl4cvvtgjp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2017-02-15 08:48:44 -0500, Robert Haas wrote:
> We got rid of the major existing use of page locks in
> 6d46f4783efe457f74816a75173eb23ed8930020, which extirpated them from
> hash indexes, and I was kind of hoping they could go away altogether,
> but we can't do that as long as GIN is using them.
Learned a new word today.
> Anyway, if we solve those problems, we can allow inserts (not updates
> or deletes, those have other problems, principally relating to combo
> CIDs) in parallel mode, which would make it possible to allow the
> kinds of things you are asking about here.
I don't think general INSERTs are safe, if you consider unique indexes
and foreign keys (both setting xmax in the simple cases and multixacts
are likely to be problematic).
> The other way of fixing this problem is to have each worker generate a
> subset of the tuples and funnel them all back to the leader through a
> Gather node; the leader then does all the inserts. That avoids having
> to solve the problems mentioned above, but it probably doesn't perform
> nearly as well.
I think it'd already be tremendously useful however. I think it'd not
be an unreasonable first step. It'd be a good fallback that'd be useful
for !insert and such anyway.
Regards,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-02-16 01:20:20 | Re: CREATE TABLE with parallel workers, 10.0? |
Previous Message | Haribabu Kommi | 2017-02-16 00:49:21 | Re: CREATE TABLE with parallel workers, 10.0? |