Re: Mini improvement: statement_cost_limit - Mailing list pgsql-hackers

On Monday 04 August 2008 03:50:40 daveg wrote:
> On Sun, Aug 03, 2008 at 10:57:55PM -0400, Robert Treat wrote:
> > 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.
>

That was one of the other use cases that was pushed forward in the past. 

> > > > 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.
>

That's great for you, I am talking in the scope of a general solution. (Note 
I'd also bet that even given the same hardware, different production loads 
can produce different relative mappings of cost vs. performance, but 
whatever)

> > 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.
>

And you'll note, I specifically said that a crude tool is better than nothing. 
But your completely ignoring that a crude tool can often end-up as a foot-gun 
once relased into the wild. 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL