Re: WIP: extensible enums

Andrew Dunstan <andrew@dunslane.net> writes:
> On 10/17/2010 03:56 PM, Tom Lane wrote:
>> [clever scheme to treat even numbered enum Oids as sorted]
>> 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.

> Thinking more about this, could we do some sort of hybrid scheme that 
> stashes the 'oids are sorted correctly' property of the type somewhat 
> like what I proposed?

I think that fundamentally doesn't work in the face of a concurrent
ALTER TYPE.  And even if it did work, by the time you've done the
cache lookup to check your stashed flag, what have you really saved?
The only way to have comparisons that are on par with current
performance is to not need to do any lookup at all.

The scenario that seems the most dangerous to me is
1. Begin transaction T1.2. T1 does cache lookup, or any other pushup you want, and   decides that the enum type is
correctlysorted.3. T2 commits an ALTER TYPE that adds a non-sorted OID.4. T3 inserts that OID in an index.5. T1
encountersthe out-of-order OID in the index.
 

If T1 is not able to recognize that the OID it's looking at is not
in-order, despite its previously cached information, it's going to lose
badly.  It's impractical to do an AcceptInvalidationMessages on every
single comparison, so AFAICT you *have to* be able to deal correctly
with enum values that were added since your cache entry was made.

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
notpresent, 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.
        regards, tom lane