From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extensible enum types |
Date: | 2010-06-21 15:01:05 |
Message-ID: | 12725.1277132465@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:
> Tom Lane wrote:
>> Well, having to do a cache lookup already makes it a couple orders of
>> magnitude more expensive than an OID comparison. However, it's hard to
>> say how much that matters in terms of total application performance.
>> We really could do with a bit of performance testing here ...
> I have done some. The performance hit is fairly horrible. Adding cache
> lookups for the enum rows to the comarison routines made a REINDEX on a
> 1m row table where the index is on an enum column (the enum has 500
> randomly ordered labels) jump from around 10s to around 70s.
Hmmm... that's bad, but I bet it's still less than the cost of comparing
NUMERICs. Also, did you make any attempt to avoid repetitive cache
lookups by storing a pointer in fn_extra (cf array comparisons)?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-06-21 16:20:59 | deprecating =>, take two |
Previous Message | Tom Lane | 2010-06-21 14:51:47 | Re: Patch: psql \whoami option |