Re: WIP: extensible enums

On 10/17/2010 03:56 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> Making that as fast as "Is this sorted? If yes, compare the two oids" or
>> even acceptably slower seems likely to be a challenge. I thought about
>> the sort of approach you suggest initially and didn't come up with
>> anything that seemed likely to work well enough.
> The fundamental problem here is that we can't tell by examining an enum
> value whether we have to apply the "fast" or "slow" comparison method.
> But what if we could?
>
> The sneaky idea that just came to me is to declare that even-numbered
> OID values can be sorted by direct comparison, whereas odd-numbered OIDs
> can't. It seems fairly easy to ensure that that property holds while
> creating the values, as long as you don't mind "burning" OIDs: if you
> get a value you don't like, just demand another one. Then, as long as
> both OIDs involved in a comparison are even, you just do a direct
> comparison and no cache entry is needed at all. When either is odd, you
> know you need a cache entry. You can also tell whether an existing
> cache entry is stale: if it doesn't contain both values then you need to
> refresh it. If it does have both, then it's good enough for the
> immediate purpose, even if there are other values it doesn't know
> about. So with this design we don't actually have to watch for inval
> events at all ... we just refresh the cache entry whenever a comparison
> finds that that's needed.

Hmm, nice. What I like about this is that it's not an all or nothing
deal. If you add one label that needs an odd Oid, most of the
comparisons will still be fast.

I think the rule for choosing the Oid for the new entry would go
something like this:

* if we're adding a label at the end and the Oid of the last entry
is even, take the first Oid that is either even and greater than
the Oid of the last entry, or odd and less than the Oid of the
last entry
* for all other positions take the first odd Oid

> The one problem I can see with this is that it's only partially
> on-disk-compatible with existing enum types: it'll almost certainly
> think that they require slow comparison, even when they don't.
> Maybe that's acceptable.

Yeah, not sure about that.

cheers

andrew