On 05/11/14 18:32, Heikki Linnakangas wrote:
On 11/05/2014 05:07 PM, Petr Jelinek wrote:
On 05/11/14 13:45, Heikki Linnakangas wrote:
In fact, if the seqam manages the current value outside the database
(e.g. a "remote" seqam that gets the value from another server),
nextval() never needs to write a WAL record.
Sure it does, you need to keep the current state in Postgres also, at
least the current value so that you can pass correct input to
sequence_alloc(). And you need to do this in crash-safe way so WAL is
necessary.
Why does sequence_alloc need the current value? If it's a "remote"
seqam, the current value is kept in the remote server, and the last
value that was given to this PostgreSQL server is irrelevant.
Hmm, I am not sure if I see this usecase as practical TBH, but I also
don't see fundamental problem with it.
That irks me with this API. The method for acquiring a new value isn't
fully abstracted behind the AM interface, as sequence.c still needs to
track it itself. That's useful for the local AM, of course, and maybe
some others, but for others it's totally useless.
Hmm, I think that kind of abstraction can only be done by passing
current tuple and returning updated tuple (yes I realize that it's what
you have been saying basically).
In general it sounds like the level of abstraction you'd want would be
one where AM cares about everything except the the code that does the
actual writes to page and WAL (but when to do those would still be
controlled completely by AM?) and the SQL interface.
I don't see how to make that work with ALTER SEQUENCE USING to be honest
and I do care quite a lot about that use-case (I think the ability to
convert the "local" sequences to 3rd party ones and back is very important).
That's not the issue I was referring to, I was talking about the page
replacement code which is not as simple now that we have potentially
dynamic size tuple and if tuples were different for different AMs the
code would still have to be able to handle that case. Setting the values
in tuple itself is not too complicated.
I don't see the problem with that. We deal with variable-sized tuples in
heap pages all the time. The max size of amdata (or the extra
AM-specific columns) is going to be determined by the block size, though.
Glad to hear that. Yes the limit is block size, I think we can live with
that at least for the moment...
--
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
