Re: WIP: extensible enums
От | Dean Rasheed |
---|---|
Тема | Re: WIP: extensible enums |
Дата | |
Msg-id | AANLkTikk=CJ=mG=aKUNmWUR2jYVkhPF_uMo+2-5HajOo@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: extensible enums (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 24 October 2010 05:26, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Well, the easy way to read a consistent view of the world is to load the > cache using an MVCC snapshot instead of SnapshotNow. The current code > structure isn't amenable to that because it's relying on a syscache to > fetch the data for it, but that seems pretty inefficient anyway. I'm > thinking of changing it around so that the enum cache gets loaded with > a regular systable_beginscan() scan, and then we could load with an > MVCC snapshot. > > I'm kind of inclined to go to the float-based representation anyway, > though, just because not having to update other rows to do an insert > seems like a good thing. But we could combine that with an MVCC > snapshot on the read side, which would make renumbering safe, which > would mean that we could auto-renumber when we ran out of code space > and not otherwise. Is that getting too complicated? > As an alternative, how about storing the sort order as an array of OIDs, in a single row in pg_type, or a new table, rather than across multiple rows in pg_enum. Code that read it would be guaranteed a consistent view of the data, and at worst, it might be missing recently added elements, which the comparison code can already deal with by re-reading the array. Regards, Dean > regards, tom lane >
В списке pgsql-hackers по дате отправления: