Re: WIP: extensible enums
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, Greg Stark <gsstark@mit.edu>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2010-10-25T01:38:41Z
Lists: pgsql-hackers
On 10/24/2010 09:20 PM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> On 10/24/2010 08:12 PM, Tom Lane wrote: >>> This shows that the bitmapset optimization really is quite effective, >>> at least for cases where all the enum labels are sorted by OID after >>> all. That motivated me to change the bitmapset setup code to what's >>> attached. This is potentially a little slower at initializing the >>> cache, but it makes up for that by still marking most enum members >>> as sorted even when a few out-of-order members have been inserted. >> That's nice. It's a tradeoff though. Bumping up the cost of setting up >> the cache won't have much effect on a creating a large index, but could >> affect to performance of retail comparisons significantly. But this is >> probably worth it. You'd have to work hard to create the perverse case >> that could result in seriously worse cache setup cost. > Well, notice that I moved the caching into typcache.c, rather than > having it be associated with query startup. So unless you're actively > frobbing the enum definition, that's going to be paid only once per > session. Oh, yes. Good. I'm just starting to look at this in detail. cheers andrew