Tom Lane wrote: > Andrew Dunstan <and...@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.
Thanks for modifying pg_upgrade so it works with this new format. The changes look good and cleaner than what I had to do for 9.0. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
