On 10/18/2010 10:52 AM, Tom Lane wrote:
> We could possibly deal with enum types that follow the existing
> convention if we made the cache entry hold a list of all the original,
> known-to-be-sorted OIDs. (This could be reasonably compact and cheap to
> probe if it were represented as a starting OID and a Bitmapset of delta
> values, since we can assume that the initial set of OIDs is pretty close
> together.) But we have to have that cache entry, and we have to consult
> it on every single comparison, so it's definitely going to be slower
> than before.
>
> 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.
OK, I've made adjustments that I think do what you're suggesting.
Patch is attached.
Alternatively this can be pulled from
<git@github.com:adunstan/postgresql-dev.git>
cheers
andrew