<br /><br /> On 10/17/2010 03:56 PM, Tom Lane wrote: <blockquote cite="mid:13685.1287345367@sss.pgh.pa.us"
type="cite"><prewrap="">Andrew Dunstan <a class="moz-txt-link-rfc2396E"
href="mailto:andrew@dunslane.net"><andrew@dunslane.net></a>writes:
</pre><blockquote type="cite"><pre wrap="">Making that as fast as "Is this sorted? If yes, compare the two oids" or
even acceptably slower seems likely to be a challenge. I thought about
the sort of approach you suggest initially and didn't come up with
anything that seemed likely to work well enough.
</pre></blockquote><pre wrap="">
The fundamental problem here is that we can't tell by examining an enum
value whether we have to apply the "fast" or "slow" comparison method.
But what if we could?
The sneaky idea that just came to me is to declare that even-numbered
OID values can be sorted by direct comparison, whereas odd-numbered OIDs
can't. It seems fairly easy to ensure that that property holds while
creating the values, as long as you don't mind "burning" OIDs: if you
get a value you don't like, just demand another one. Then, as long as
both OIDs involved in a comparison are even, you just do a direct
comparison and no cache entry is needed at all. When either is odd, you
know you need a cache entry. You can also tell whether an existing
cache entry is stale: if it doesn't contain both values then you need to
refresh it. If it does have both, then it's good enough for the
immediate purpose, even if there are other values it doesn't know
about. So with this design we don't actually have to watch for inval
events at all ... we just refresh the cache entry whenever a comparison
finds that that's needed.
</pre></blockquote><br /> Hmm, nice. What I like about this is that it's not an all or nothing deal. If you add one
labelthat needs an odd Oid, most of the comparisons will still be fast.<br /><br /> I think the rule for choosing the
Oidfor the new entry would go something like this:<br /><ul><li>if we're adding a label at the end and the Oid of the
lastentry is even, take the first Oid that is either even and greater than the Oid of the last entry, or odd and less
thanthe Oid of the last entry<li>for all other positions take the first odd Oid</ul><br /><br /><blockquote
cite="mid:13685.1287345367@sss.pgh.pa.us"type="cite"><pre wrap="">
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.
</pre></blockquote><br /><br /><br /> Yeah, not sure about that. <br /><br /> cheers<br /><br /> andrew<br />