Horton

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

Ants Aasma <ants@cybertec.at>

View thread
From: Ants Aasma <ants@cybertec.at>
To: Sergey Koposov <koposov@ast.cam.ac.uk>
Cc: Merlin Moncure <mmoncure@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Florian Pflug <fgp@phlo.org>, Jeff Janes <jeff.janes@gmail.com>, pgsql-hackers@postgresql.org, Stephen Frost <sfrost@snowman.net>
Date: 2012-06-06T18:54:15Z
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 Wed, Jun 6, 2012 at 2:27 PM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote:
> I've quickly tested your lockfree-getbuffer.patch patch with the test case
> you provided and I barely see any improvement (2% at max)
> https://docs.google.com/open?id=0B7koR68V2nM1QVBxWGpZdW4wd0U
> tested with 24 core (48 ht cores, Xeon E7- 4807).
> Although the tps vs number of threads looks weird....

Was this the range scan on the test table? (sorry about the error in
the query, the x should really be id) In that case the results look
really suspicious. My machine (4 cores, no ht, @ 4GHz, newer arch)
peaked at 90tps with the stated configuration. Even when upping the
shared_buffers and enabling indexonlyscan I didn't see more than about
540tps per thread. The test is designed to exercise buffer eviction,
doing about 9800 buffer reads per transaction with 32MB of buffers.

Ants Aasma
-- 
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de