On Wed, 6 Oct 1999, Thomas Lockhart wrote:
> > I can't get excited about changing this from the standpoint of
> > functionality, because AFAICS there is no added functionality.
> > But if we're looking bad on a recognized benchmark maybe we
> > should do something about it.
>
> We are looking bad on a benchmark designed to show MySQL in the best
> possible light, and to show other DBs at their worst. The maintainers
> of that benchmark have no interest in changing that emphasis (e.g. we
> are still reported as not supporting HAVING, even though we have
> demonstrated to them that we do; this is the same pattern we have seen
> earlier).
>
> The last time I looked at it, there were ~30% factual errors in the
> reported results for Postgres; no telling what errors are there for
> other products. imho it is a waste of time to address a bogus
> benchmark, unless someone wants to take it up as a hobby. I'm a bit
> busy right now ;)
My opinion on this tends to be that, in the HAVING case, we are the only
one that doesn't support it w/o aggregates, so we altho we do follow the
spec, we are making it slightly more difficult to migrate from 'the
others' to us...
So far, Luuk has appeared to be relatively open as far as investigating
the discrepencies in the report...but, since he doesn't *know* PostgreSQL,
he has no way of knowing what is wrong, and that is where, I think, we
should be trying to help support our end of things...
If Luuk were to come back and tell us that he absolutely won't change
anything, then, IMHO, there is a problem...but, thanks to his test, Bruce
made some changes to how we handle our comments to fix a bug...and Luuk
told us that he fixed the HAVING test such that HAVING w/o aggregates
doesn't fail the test...
Benchmarks, IMHO, always try to favor the 'base product' that is being
advertised...but, more often then not, its because the person doing the
benchmarking knows that product well enough to be able to 'tweak' it to
perform better...Luuk, so far as I believe, is willing to be "educated in
PostgreSQL"...I don't think its right for us to stifle that, is it?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
