On 10/19/2010 12:21 AM, Andrew Dunstan 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.
I've discovered and fixed a couple more bugs in this. I have one or two more things to fix and then I'll send a new patch.
Meanwhile, I've been testing a database that was upgraded from 9.0, so it has a lot of odd-numbered Oids. It's not really clear from performance testing that the bitmap is a huge win, or even a win at all. (Of course, my implementation might suck too.) I'll continue testing.
cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
