Re: WIP: extensible enums - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: WIP: extensible enums
Date
Msg-id AANLkTinX1N6xNtfyr7m7+UN+V1_zoyBqQ5ey35cz4mgQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP: extensible enums  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: extensible enums
Re: WIP: extensible enums
List pgsql-hackers
On 18 October 2010 15:52, Tom Lane <tgl@sss.pgh.pa.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.

Regards,
Dean


>                        regards, tom lane
>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: extensible enums
Next
From: Robert Haas
Date:
Subject: Re: string function - "format" function proposal