>
> ISTR that what ended up killing the enthusiasm for this was that most people
> realized that this GUC was just a poor tool to take a stab at solving other
> problems (ie. rate limiting cpu for queries).
I'm not concerned with that, I want developers to have feed back on costs in
a way that is obvious.
> > > I think a variation on this could be very useful in development and test
> > > environments. Suppose it raised a warning or notice if the cost was over
> > > the limit. Then one could set a limit of a few million on the development
> > > and test servers and developers would at least have a clue that they
> > > needed to look at explain for that query. As it is now, one can exhort
> > > them to run explain, but it has no effect. Instead we later see queries
> > > killed by a 24 hour timeout with estimated costs ranging from "until they
> > > unplug the machine and dump it" to "until the sun turns into a red
> > > giant".
> >
> > Great argument. So that's 4 in favour at least.
> >
>
> Not such a great argument. Cost models on development servers can and often
> are quite different from those on production, so you might be putting an
> artifical limit on top of your developers.
We load the production dumps into our dev environment, which are the same
hardware spec, so the costs should be identical.
> I still think it is worth revisiting what problems people are trying to solve,
> and see if there are better tools they can be given to solve them. Barring
> that, I suppose a crude solution is better than nothing, though I fear people
> might point at the crude solution as a good enough solution to justify not
> working on better solutions.
Alerting developers and QA to potentially costly queries would help solve
some of the probems we are trying to solve. Better tools are welcome, an
argument that the good is the enemy of the best so we should be content with
nothing is not.
-dg
--
David Gould daveg@sonic.net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment