Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Date
Msg-id 788.1338578040@sss.pgh.pa.us
Whole thread Raw
In response to Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Next
From: Peter Geoghegan
Date:
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)