Re: Sequence Access Method WIP
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Simon Riggs <simon@2ndQuadrant.com>, Petr Jelinek <petr@2ndquadrant.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2014-12-02T19:21:28Z
Lists: pgsql-hackers
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
Commits
-
Add missing gss option to msvc config template
- 3063e7a84026 9.6.0 cited