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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com