Re: Sequence Access Method WIP
От | Petr Jelinek |
---|---|
Тема | Re: Sequence Access Method WIP |
Дата | |
Msg-id | 5685BF97.7080800@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Sequence Access Method WIP (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Sequence Access Method WIP
|
Список | pgsql-hackers |
Hi, here is another try at this. I had some more time to think about various corner cases (like the sequence not having TOAST). I decided for this version to try bit different approach and that is to use custom datatype for the sequence access method state. So there is one extra amstate column and the access method defines the custom type. The idea is that the custom type should be fixed width so that we can do proper checks during the creation of access method for size and stuff. It also makes the interface bit cleaner as we can provide method for reading and saving of the state and abstract the internals more nicely. It also solves the issues with critical sections vs memory allocations when the access methods wants to save completely new state. It also means that get_state and set_state interfaces just work with text representation of custom type, no need to have complex conversions to arrays and back. One downside is that this means access methods can't use composite types as those are not fixed width (nor plain) so the names of the individual items in the output are somewhat hidden (see the modified create_view test for example of how this affects things). Other than that, this is based on the new am api by Alexander Korotkov [1]. It extends it by adding another column called amkind to the pg_am which can have either value "i" for index or "S" for sequence (same as relkind in pg_class for those). I didn't attach DDL and the gapless sequence yet, mainly because I don't want to waste time rewriting it again in case we can't agree that this approach is good (based on the long discussion and resulting several rewrites wrt the multiple columns vs bytea previously). [1] https://commitfest.postgresql.org/8/336/ -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: