Simon Riggs wrote: > On Mon, 2010-05-03 at 22:45 -0400, Bruce Momjian wrote: > > > As I remember, 9.0 has two behaviors: > > > > o master delays vacuum cleanup > > o slave delays WAL application > > > > and in 9.1 we will be adding: > > > > o slave communicates snapshots to master > > > How would this figure into what we ultimately want in 9.1? > > We would still want all options, since "slave communicates snapshot to > master" doesn't solve the problem it just moves the problem elsewhere. > It's a question of which factors the user wishes to emphasise for their > specific use. > > > I understand Simon's point that the two behaviors have different > > benefits. However, I believe few users will be able to understand when > > to use which. > > If users can understand how to set NDISTINCT for a column, they can > understand this. It's not about complexity of UI, its about solving > problems. When people hit an issue, I don't want to be telling people > "we thought you wouldn't understand it, so we removed the parachute". > They might not understand it *before* they hit a problem, so what? But > users certainly will afterwards and won't say "thanks" if you prevent an > option for them, especially for the stated reason. (My point about > ndistinct: 99% of users have no idea that exists or when to use it, but > it still exists as an option because it solves a known issue, just like > this.)
Well, this is kind of my point --- that if few people are going to need a parameter and it is going to take us to tell them to use it, it isn't a good parameter because the other 99.9% are going to stare at the parameters and not konw what it does or how it is different from other similar parameters. Adding another parameter might help 0.1% of our users, but it is going to confuse the other 99.9%. :-( -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
