From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: A note about hash-based catcache invalidations |
Date: | 2011-08-17 06:54:38 |
Message-ID: | 4E4B65AE.9030002@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-08-17 06:59:41 | Re: synchronized snapshots |
Previous Message | senthilnathan | 2011-08-17 05:39:02 | Re: Backup's from standby |