Re: WIP: extensible enums - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: extensible enums
Date
Msg-id 25742.1287969658@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: extensible enums  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: WIP: extensible enums
Re: WIP: extensible enums
Re: WIP: extensible enums
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: Extensions, this time with a patch
Next
From: Tom Lane
Date:
Subject: Re: Extensions, this time with a patch