On 2014-11-24 13:16:24 +0200, Heikki Linnakangas wrote: > To be clear: I don't think this API is very good for its stated purpose, for > implementing global sequences for use in a cluster. For the reasons I've > mentioned before. 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)
I think that reason isn't particularly good. The practical applicability for such a implementation doesn't seem to be particularly large. > 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. My main problem with that approach is that it pretty much nails the door shut for moving sequences into a catalog table instead of the current, pretty insane, approach of a physical file per sequence. Currently, with our without seqam, it'd not be all that hard to force it into a catalog, taking care to to force each tuple onto a separate page... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
