Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Sergey Koposov <koposov@ast.cam.ac.uk>, Jeff Janes <jeff.janes@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-05-25T16:38:01Z
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

Merlin Moncure <mmoncure@gmail.com> writes:
> On Fri, May 25, 2012 at 11:17 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> Didn't we implement a system whereby this is exactly what we intend to
>> happen on the read side- that is, everyone doing a SeqScan gangs up on
>> one ring buffer and follows it, which we felt was going to dramatically
>> improve performance in some cases?

> yeah:
> ...
> I wonder if the logic here is just being too strict...

I don't recall how much evidence there is behind the NBuffers/4 threshold.
Maybe that needs some tuning?

			regards, tom lane