Re: VACUUM FULL versus system catalog cache invalidation

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 12.08.2011 21:49, Robert Haas wrote:
>> I don't think it really matters whether we occasionally blow away an
>> entry unnecessarily due to a hash-value collision.  IIUC, we'd only
>> need to worry about hash-value collisions between rows in the same
>> catalog; and the number of entries that we have cached had better be
>> many orders of magnitude less than 2^32.  If the cache is large enough
>> that we're having hash value collisions more than once in a great
>> while, we probably should have flushed some entries out of it a whole
>> lot sooner and a whole lot more aggressively, because we're likely
>> eating memory like crazy.

> What would suck, though, is if you have an application that repeatedly 
> creates and drops a temporary table, and the hash value for that happens 
> to match some other table in the database. catcache invalidation would 
> keep flushing the entry for that other table too, and you couldn't do 
> anything about it except for renaming one of the tables.

> Despite that, +1 for option #2. The risk of collision seems acceptable, 
> and the consequence of a collision wouldn't be too bad in most 
> applications anyway.

Yeah.  Also, to my mind this is only a fix that will be used in 9.0 and
9.1 --- now that it's occurred to me that we could use tuple xmin/xmax
to invalidate catcaches instead of recording individual TIDs, I'm
excited about doing that instead for 9.2 and beyond.  I believe that
that could result in a significant reduction in sinval traffic, which
would be a considerable performance win.
        regards, tom lane