On 08/11/14 03:10, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:26 PM, Petr Jelinek <p...@2ndquadrant.com> wrote:
My main problem is actually not with having tuple per-seqAM, but more
with the fact that Heikki does not want to have last_value as compulsory
column/parameter. How is the new AM then supposed to know where to pick
up and if it even can pick up?
That seems pretty well impossible to know anyway. If the pluggable AM
was handing out values at random or in some unpredictable fashion,
there may be no well-defined point where it's safe for the default AM
to resume. Granted, in the case of replication, it probably is
possible, and maybe that's important enough to be worth catering to.
While this is true, I think 99% of this use-case in practice is about
converting existing schema with "local" sequence to some other sequence
and perhaps fixing schema after people create sequence using wrong AM
because their default is not what they thought it is.
And obviously, once the last_value is part of the compulsory columns we
again have to WAL log all the time for the use-case which Heikki is using as
model, so it does not help there (just to clear what my point was about).
But I don't know what to do about that. :-(
Me neither and I don't think this is actually solvable, we either have
last_value and logcnt as mandatory columns and the central sequence
server example Heikki is talking about will be impacted by this, or we
leave those columns to AM implementations and we lose the ability to do
AM change for majority of cases, and also IMHO most AMs will then have
to implement their own last_value and logcnt logic anyway.
Honestly, I am still not convinced that the centralized sequence server
with no local caching is something we should be optimizing for as that
one will suffer from performance problems anyway. And it can ignore the
last_value input from postgres if it choses to, so it's not like the
currently proposed patch forbids implementation of such AMs.
--
Petr Jelinek 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
