Re: A note about hash-based catcache invalidations

On 17.08.2011 00:17, Tom Lane wrote:
> I'm looking into the idea I mentioned earlier:
>
>> All is not entirely lost, however: there's still some possible
>> performance benefit to be gained here, if we go to the scheme of
>> identifying victim catcache entries by hashvalue only.  Currently,
>> each heap_update in a cached catalog has to issue two sinval messages
>> (per cache!): one against the old TID and one against the new TID.
>> We'd be able to reduce that to one message in the common case where the
>> hashvalue remains the same because the cache key columns didn't change.
>
> Removing the tuple ID from sinval messages turns out to have slightly
> wider impact than I thought at first, because the current coding passes
> those to callback functions registered with
> CacheRegisterSyscacheCallback, and there are a lot of 'em.  However,
> only one of them seems to be doing anything with the tuplePtr argument,
> namely PlanCacheFuncCallback.  We can make it work with the hash value
> instead, which will be about as good as what we're doing now.
>
> Any objections to that plan?

A callback might be using the tuple ID in a way that fails if VACUUM 
FULL moves the tuple, so I think we *have* to change it. (as you did 
already)

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com