On Tue, 2006-04-25 at 13:43 -0400, Tom Lane wrote:
What I'm considering doing to fix that is require any change to a
btree's metapage data to send out a relcache inval message for the
index. That will force all backends to flush the stale cache item
not later than the start of their next
Simon Riggs [EMAIL PROTECTED] writes:
Hmmm I'm slightly worried that frequently-churning small tables will
be made even slower by this. What do you think?
How so?
So we would be able to cache other items also?
Only to the extent that you can guarantee a stale cache entry isn't a
problem.
On Wed, 2006-04-26 at 12:53 -0400, Tom Lane wrote:
So we would be able to cache other items also?
Only to the extent that you can guarantee a stale cache entry isn't a
problem. We've already done the analysis involved for the existing
metapage entries, but anything else would require more
Tom Lane wrote:
Some experimentation over the weekend turned up the result that $SUBJECT
is a good idea. I had never thought about this much before, figuring
that in a heavily-used index the metapage would stay in cache anyway and
so fetching it at the start of each index search isn't
