Horton

Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

Sergey Koposov <koposov@ast.cam.ac.uk>

View thread
From: Sergey Koposov <koposov@ast.cam.ac.uk>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-05-25T13:18:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve bulk-insert performance by keeping the current target buffer pinned

On Fri, 25 May 2012, Merlin Moncure wrote:

> These are all on the buffer partition locks.  That makes sense...I was
> wrong earlier: this case was in fact 'create table as', not 'insert
> select' which rules out both the freelist lock and the wal insert lock
> because create table as gets to use both a bulk insert strategy and
> wal avoiding logic (assuming wal log level is not 'archive or higher'.
> So, why aren't the lock partitions helping here?

FYI the WAL level is default, and here are the relevand changed params 
from the .conf (autovacuum was disabled but the data was vacuumed 
manually).

max_connections = 100                   # (change requires restart)
shared_buffers = 10GB                   # min 128kB
work_mem = 500MB                                # min 64kB
maintenance_work_mem = 500MB            # min 1MB
synchronous_commit = off                # synchronization level;
checkpoint_segments = 20                # in logfile segments, min 1, 16MB each
enable_hashjoin = off
enable_mergejoin = off
effective_cache_size = 10GB
autovacuum = off                        # Enable autovacuum subprocess?  'on'


Regards,
 	S

*****************************************************
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA, Cambridge, UK
Tel: +44-1223-337-551 Web: http://www.ast.cam.ac.uk/~koposov/