Re: Parallel (concurrent) inserts?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Ivan Voras <ivoras(at)freebsd(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Parallel (concurrent) inserts?
Date: 2012-05-25 23:36:48
Message-ID: CAMkU=1wNY0wUvRTR7w+0r81sVmEZOyKJMZU9Xy0xaumixxbr0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, May 25, 2012 at 3:04 PM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
> Hello,
>
> I'm wondering if there is ia document describing which guarantees (if
> any) PostgreSQL makes about concurrency for various operations? Speaking
> in general (i.e. IO can handle it, number of CPU cores and client
> threads is optimal), are fully concurrent operations (independant and
> non-blocking) possible for:

By "fully concurrent" do you mean that there is no detectable
sub-linear scaling at all? I'm pretty sure that no such guarantees
can be made.

> 1) An unindexed table?

For concurrent bulk loads, there was severe contention on generating
WAL between concurrent bulk loaders. That is greatly improved in the
upcoming 9.2 release.

> 2) A table with 1+ ordinary (default btree) indexes? (are there
> constraints on the structure and number of indexes?)

This will be limited by contention for generating WAL. (Unless
something else limits it first)

> 3) A table with 1+ unique indexes?

If more than one transaction attempts to insert the same value, one
has to block until the other either commits or rollbacks.

> 4) A table with other objects on it (foreign keys, check constraints, etc.)?

Same as above. If they try to do conflicting things, they don't
continue operating concurrently.

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Ivan Voras 2012-05-25 23:56:57 Re: Parallel (concurrent) inserts?
Previous Message Josh Berkus 2012-05-25 23:13:54 Re: Parallel (concurrent) inserts?