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: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, Florian Pflug <fgp@phlo.org>, Merlin Moncure <mmoncure@gmail.com>, Sergey Koposov <koposov@ast.cam.ac.uk>, pgsql-hackers@postgresql.org, Stephen Frost <sfrost@snowman.net>
Date: 2012-06-01T19:14:00Z
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

Robert Haas <robertmhaas@gmail.com> writes:
> Another thought is that if the problem is limited to the root index
> block, then we could consider less general solutions, like allowing
> backends to cache the root index block and sending some kind of
> invalidation when it gets split.

Possibly worth noting here that we already do exactly that for btree
metapages.  However, I believe that case is a bit different, in that
using slightly stale metapage data is nonfatal.  Also, anything like
this can be a win only if the cached data can be expected to have pretty
long lifetime; so you would not want to cache the root page until the
index had gotten large enough that root page changes were infrequent.
Not sure how that could be mechanized ...

			regards, tom lane