Re: Mini improvement: statement_cost_limit

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: daveg <daveg(at)sonic(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Mini improvement: statement_cost_limit
Date: 2008-08-04 21:19:50
Message-ID: 200808041719.50577.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2008-08-04 21:39:28 Re: Automatic Client Failover
Previous Message Jonah H. Harris 2008-08-04 21:17:59 Re: Automatic Client Failover