Re: WIP: extensible enums
От | Andrew Dunstan |
---|---|
Тема | Re: WIP: extensible enums |
Дата | |
Msg-id | 4CBC89BE.5060100@dunslane.net обсуждение исходный текст |
Ответ на | Re: WIP: extensible enums (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: WIP: extensible enums
|
Список | pgsql-hackers |
On 10/18/2010 01:40 PM, Dean Rasheed wrote: > On 18 October 2010 15:52, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> So I'm thinking the comparison procedure goes like this: >> >> 1. Both OIDs even? >> If so, just compare them numerically, and we're done. >> >> 2. Lookup cache entry for enum type. >> >> 3. Both OIDs in list of known-sorted OIDs? >> If so, just compare them numerically, and we're done. >> >> 4. Search the part of the cache entry that lists sort positions. >> If not both present, refresh the cache entry. >> If still not present, throw error. >> >> 5. Compare by sort positions. >> >> Step 4 is the slowest part but would be avoided in most cases. >> However, step 2 is none too speedy either, and would usually >> be required when dealing with pre-existing enums. >> > I was thinking that steps 2-5 could be sped up by doing something like: > > 2. If first time in: > Build a lightweight hash map: [ oid -> sort position ] with > all the enum values > > 3. Look up each oid in the hash map > If not both present, rebuild the hash map > If still not present, throw error. > > 4. Compare by sort positions. > > I think the hash map lookups could be made pretty quick, if we're > prepared to write a bit of dedicated code there rather than relying on > the more general-purpose caching code. > If you have want to work on it and prove it's going to be better, please do. I'm not convinced it will do a whole lot better than a binary search that in most cases will do no more than a handful of probes. cheers andrew
В списке pgsql-hackers по дате отправления: