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: Florian Pflug <fgp@phlo.org>, Robert Haas <robertmhaas@gmail.com>, Sergey Koposov <koposov@ast.cam.ac.uk>, Jeff Janes <jeff.janes@gmail.com>, pgsql-hackers@postgresql.org, Stephen Frost <sfrost@snowman.net>
Date: 2012-06-01T13:45:54Z
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:
> A potential issue with this line of thinking is that your pin delay
> queue could get highly pressured by outer portions of the query (as in
> the OP's case)  that will get little or no benefit from the delayed
> pin.  But choosing a sufficiently sized drain queue would work for
> most reasonable cases assuming 32 isn't enough?  Why not something
> much larger, for example the lesser of 1024, (NBuffers * .25) /
> max_connections?  In other words, for you to get much benefit, you
> have to pin the buffer sufficiently more than 1/N times among all
> buffers.

Allowing each backend to pin a large fraction of shared buffers sounds
like a seriously bad idea to me.  That's just going to increase
thrashing of what remains.

More generally, I don't believe that we have any way to know which
buffers would be good candidates to keep pinned for a long time.
Typically, we don't drop the pin in the first place if we know we're
likely to touch that buffer again soon.  btree root pages might be an
exception, but I'm not even convinced of that one.

			regards, tom lane