On 13/05/15 12:56, Heikki Linnakangas wrote:
On 05/13/2015 07:10 AM, Alvaro Herrera wrote:
Heikki, do you have time to go through this at this point?
I'm afraid I won't :-(. I did intend to, but looking at the calendar, I
won't have the time to review this thoroughly enough to commit. Sorry.
We discussed using a single amdata column vs. any number of am-specific
columns. We settled on amdata, but I'm still not 100% convinced that's
the best approach. Just as a data point, this removes the log_cnt field
and moves it into amdata in a non-human-readable format. So for someone
who only uses the local seqam, this just makes things slightly worse.
For more complicated seqam's, it would be even more important to display
the state in a human-readable format. Perhaps it's OK that each seqam
provides its own functions or similar to do that, but I'd like to
revisit that decision.
I do think it's ok for seqam to provide functions that can give you the
data in human readable form.
I think main argument against custom human readable columns is that it
will kill any possibility to have common storage for sequences.
There is also additional complexity in the API required for that.
The performance implications are probably small as one could still
define opaque bytea column and store the data same way a now.
I still don't like the serial_sequenceam GUC. Not sure what to do
instead. Needs some thought.
I think it would be ok if this issue was solved by follow-up patch at
later time.
--
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
