Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] CREATE TABLE with parallel workers, 10.0? |
Дата | |
Msg-id | 20170216011313.tsz344sl4cvvtgjp@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] CREATE TABLE with parallel workers, 10.0? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?
Re: [HACKERS] CREATE TABLE with parallel workers, 10.0? |
Список | 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
В списке pgsql-hackers по дате отправления: