Re: WIP: extensible enums
От | Dean Rasheed |
---|---|
Тема | Re: WIP: extensible enums |
Дата | |
Msg-id | AANLkTimOJRzpBx62T_NrvK4FPVdOfwT00vqc3a+qeq9a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: extensible enums (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: extensible enums
|
Список | pgsql-hackers |
On 24 October 2010 17:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg Stark <gsstark@mit.edu> writes: >> There's nothing magic about the integral types here. If you use a >> string then you could always split by making the string longer. > > The entire objective here is to make enum comparisons fast. Somehow, > going to a non-primitive data type to represent the sort values does > not seem like a win from that perspective. > > (Likewise for Dean's suggestion for an array of another kind.) > The point with an OID array is that you wouldn't need to store the enumsortorder values at all. The sort order would just be the index of the OID in the array. So the comparison code would read the OID array, traverse it building an array of enum_sort structs {oid, idx}, sort that by OID and cache it. Then do binary searches to efficiently find the index (i.e., sort order) for any given OID. That's pretty much what the comparison code is doing now, except without explicitly stored sort positions. The reason I thought this might help is that it would be a single atomic operation to read the whole enum sort order, so you'd never get a mix of old and new sort positions, if another transaction was altering the enum. > What I'm currently thinking is that we should actually use float4 not > float8. That eliminates any concerns about making the representation > larger than it was before. We'll definitely have to have the logic > to do renumbering, but it'll still be an exceedingly rare thing in > practice. With float4 the implementation would fail at somewhere > around 2^24 elements in an enum (since even with renumbering, there > wouldn't be enough bits to give each element a distinguishable value). > I don't see that as a real objection, and anyway if you were trying > to have an enum with many elements, you'd want the in-memory > representation to be compact. > That seems like a lot of additional complexity to do the renumbering, and you'd have to make the comparison code safe against a concurrent renumbering. Regards, Dean > regards, tom lane >
В списке pgsql-hackers по дате отправления: