From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: extensible enums |
Date: | 2010-10-25 01:20:58 |
Message-ID: | 25742.1287969658@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-10-25 01:22:57 | Re: Extensions, this time with a patch |
Previous Message | Itagaki Takahiro | 2010-10-25 01:04:50 | Re: Extensions, this time with a patch |