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
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
prob
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
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 cos
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 costing any extra
I/O. Tha
