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