On Tue, Oct 19, 2010 at 10:19, Thom Brown <thom@linux.com> wrote:
> On 19 October 2010 05:21, Andrew Dunstan <andrew@dunslane.net> wrote:
>>
>>
>> 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>
>
> Andrew, can't you get your own repo at git.postgresql.org?
He certainly could, but github provides more features and a nicer look
:-) And since it's git, it doesn't matter where the repo is.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/