Re: Sequence Access Method WIP - Mailing list pgsql-hackers
From | Petr Jelinek |
---|---|
Subject | Re: Sequence Access Method WIP |
Date | |
Msg-id | 5487B112.9090304@2ndquadrant.com Whole thread Raw |
In response to | Re: Sequence Access Method WIP (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Responses |
Re: Sequence Access Method WIP
|
List | pgsql-hackers |
On 24/11/14 12:16, Heikki Linnakangas wrote: > I'd like to see two changes to this proposal: > > 1. Make the AM implementation solely responsible for remembering the > "last value". (if it's a global or remote sequence, the current value > might not be stored in the local server at all) > > 2. Instead of the single amdata field, make it possible for the > implementation to define any number of fields with any datatype in the > tuple. That would make debugging, monitoring etc. easier. > Hi, here is the new version for next CF, there are several rough edges (more about that later) but I think it's ready for more feedback. I did change the API quite considerably (rewrite is the word I believe). Instead of trying to put smarts on one or the other side of the API, I basically created 2 APIs, one is the seqam which is responsible for maintaining the sequence data and the other is sequence storage API provided by postgres backend. This means that backend cares purely about storage, and local caching while AM cares about the data inside sequence, and decides when to WAL. I'll start with storage API description: - sequence_open(Oid) - open sequence with given Oid and returns SequenceHandle (opens relation in share lock only) - sequence_read_tuple(SequenceHandle) - returns heap tuple of the sequence, this will also do the buffer locking - sequence_save_tuple(SequenceHandle, newtuple, do_wal) - updates the buffer with new sequence, optionally does WAL logging, newtuple can be NULL in which case the tuple is not replaced (this is performance optimization for sequences that don't need varlena/nullable columns and can update everything inplace) - sequence_release_tuple(SequenceHandle) - unlocks previously locked buffer - usable for synchronization inside the seqam implementation, the gapless sequence uses this - sequence_close(SequenceHandle) - closes the sequence handle, also unlocks buffer if needed - sequence_needs_wal(SequenceHandle) - returns true if sequence needs wal, that is if the last wal write happened before last checkpoint - this is a little bit low level but I don't see a way around it if the local sequence is supposed to maintain last_value and logcnt itself, also we have similar function for relations (that checks for different things but naming and usage is similar) so it's probably not too bad The SequenceHandle is opaque struct so no gory details seen by the AM. Now for the actual sequence AM API: - seqam_extra_columns(Oid) - returns list of custom columns needed by specified sequenceAM - seqam_init - Initializes the columns for the custom sequenceAM, used when creating, altering or resetting sequence. It gets sequenceam Oid, sequence options, reloptions on input and returns updated values and nulls arrays. - seqam_alloc - Allocates new sequence values. It gets sequence relation, handle and how many new values the backend wants and returns first and last allocated value. - seqam_setval - implements setval() support - seqam_dump_state - pg_dump support - seqam_restore_state - pg_dump support The API is slightly bigger, but it also includes proper support for dumping and restoring via pg_dump and seems somewhat cleaner, plus the synchronous and asynchronous APIs are now same and no callbacks anywhere (if AM needs to do something asynchronously it just calls the storage API). There is also gapless sequence contrib module included as separate patch, it's missing proper locking during dump/restore atm but otherwise should be fully working (see tests). I am also using it for testing the ALTER TABLE USING. About the rough edges: - The AlterSequence is not prettiest code around as we now have to create new relation when sequence AM is changed and I don't know how to do that nicely - I am not sure if I did the locking, command order and dependency handling in AlterSequence correcly - I removed the setval3 since there is no guarantee that sequence will have is_called parameter but there is now proper pg_dump support so it's not needed for pg_dump usecase, but it's still incompatible change - ResetSequence basically does ALTER SEQUENCE RESET internally instead calling setval now because of the above - there are no docs for the C APIs yet - I don't even know where those should be placed btw, would appreciate suggestions (I have same problem with committs API docs) -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Attachment
pgsql-hackers by date: