On 10/24/2010 09:20 PM, 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.
Oh, yes. Good. I'm just starting to look at this in detail.
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
