Re: Mini improvement: statement_cost_limit

On Monday 04 August 2008 15:56:25 daveg wrote:
> On Mon, Aug 04, 2008 at 02:35:07PM -0400, Robert Treat wrote:
> > On Monday 04 August 2008 03:50:40 daveg wrote:
> >
> > 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)
>
> Even on different hardware it would still likely warn of mistakes like
> products due to missing join conditions etc.
>

See, this is what we ended up talking about before. Someone will say "I'd like 
to prevent my devs from accidentally doing queries with cartesian products" 
and they will use this to do it... but that will only work in some cases, so 
it becomes a poor tool to solve a different problem. 

BTW, what I really love about statement costs, is that they aren't even 
reliable on the same machine with the same data. I have seen query plans 
which run on the same data on the same machine where the resultant query 
runtime can vary from 2 hours to 5 hours, depending on how much other 
concurrent traffic is on the machine. Awesome eh? 

> > > > 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.
>
> I released somewhat after I sent the above that it might have sounded a bit
> snippy. I hope I have not offended.
>
> > But your completely ignoring that a crude tool can often end-up as a
> > foot-gun once relased into the wild.
>
> I'm suggesting a warning, or even just a notice into the logs, I don't see
> the footgun. What am I missing?
>

The footgun in my mind is that people will think this solves a number of 
problems even though it doesnt solve them well.  However, the footgun for you 
might be that the current proposal will actually abort the query, not emit a 
warning (not sure if that changes your opinion of it).  

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