Re: WIP: extensible enums

On 17 October 2010 18:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>