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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
