Re: WIP: extensible enums

On 10/18/2010 01:40 PM, Dean Rasheed wrote:
> On 18 October 2010 15:52, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So I'm thinking the comparison procedure goes like this:
>>
>> 1. Both OIDs even?
>> If so, just compare them numerically, and we're done.
>>
>> 2. Lookup cache entry for enum type.
>>
>> 3. Both OIDs in list of known-sorted OIDs?
>> If so, just compare them numerically, and we're done.
>>
>> 4. Search the part of the cache entry that lists sort positions.
>> If not both present, refresh the cache entry.
>> If still not present, throw error.
>>
>> 5. Compare by sort positions.
>>
>> Step 4 is the slowest part but would be avoided in most cases.
>> However, step 2 is none too speedy either, and would usually
>> be required when dealing with pre-existing enums.
>>
> I was thinking that steps 2-5 could be sped up by doing something like:
>
> 2. If first time in:
> Build a lightweight hash map: [ oid -> sort position ] with
> all the enum values
>
> 3. Look up each oid in the hash map
> If not both present, rebuild the hash map
> If still not present, throw error.
>
> 4. Compare by sort positions.
>
> I think the hash map lookups could be made pretty quick, if we're
> prepared to write a bit of dedicated code there rather than relying on
> the more general-purpose caching code.
>

If you have want to work on it and prove it's going to be better, please
do. I'm not convinced it will do a whole lot better than a binary search
that in most cases will do no more than a handful of probes.

cheers

andrew