On 17 October 2010 18:53, Tom Lane <tgl@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
>