Re: Sequence Access Method WIP
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Petr Jelinek <petr@2ndquadrant.com>,
Simon Riggs <simon@2ndquadrant.com>, Andres Freund <andres@2ndquadrant.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2015-05-13T11:12:56Z
Lists: pgsql-hackers
On 13 May 2015 at 11:56, Heikki Linnakangas <hlinnaka@iki.fi> 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. > > I haven't looked at the CREATE/DROP ACCESS METHOD FOR SEQUENCE syntax > patch at all yet. > > 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 still don't like the serial_sequenceam GUC. Not sure what to do instead. > Needs some thought. This has had around 2 years of thought at this point. I don't agree it needs more thought. There is one clear use case for this and it is of benefit to many distributed architectures. I don't see what calamity will occur if we commit this. If you don't want a sequence AM, don't ever use this. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Add missing gss option to msvc config template
- 3063e7a84026 9.6.0 cited