On 17 October 2010 18:53, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> The missing piece in this is how to determine when the typcache entry >> has to be flushed. That should be driven by sinval signalling. > > On reflection that doesn't seem good enough. Immediately after someone > else has committed an ALTER TYPE, your typcache entry is out of date, > and won't be updated until you get around to noticing the SI signal. > I was thinking that wouldn't matter because you'd never need to make a > comparison involving the new enum value --- it couldn't be in any table > rows you'd see as committed good. But this is wrong because you might > have to make index comparisons involving the new value, even before you > consider that the rows the index entries reference are good. > > We could fix that with Dean's idea of reloading the cache whenever > we see that we are being asked to compare a value we don't have in the > cache entry. However, that assumes that we even notice that it's not > in the cache entry. If we're trying to use "fast" comparison then we > wouldn't notice that. >
That makes me think maybe the "fast" and "slow" comparisons should both be done the same way, having a cache so that we notice immediately if we get a new value. Obviously that's not going to be as fast as the current "fast" method, but the question is, can it be made sufficiently close? I think the current sort+bsearch method is always going to be significantly slower, but perhaps a dedicated hash table algorithm might work. Regards, Dean > So the hard part of this really is to force other backends to switch > from "fast" to "slow" comparison in a timely fashion when an ALTER makes > that necessary. Right offhand I don't see any good way to do that, > at least not while having the "fast" method as fast as it is now. > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
