Re: Mini improvement: statement_cost_limit - Mailing list pgsql-hackers
From | Robert Treat |
---|---|
Subject | Re: Mini improvement: statement_cost_limit |
Date | |
Msg-id | 200808041719.50577.xzilla@users.sourceforge.net Whole thread Raw |
In response to | Re: Mini improvement: statement_cost_limit (daveg <daveg@sonic.net>) |
Responses |
Re: Mini improvement: statement_cost_limit
(daveg <daveg@sonic.net>)
|
List | 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
pgsql-hackers by date: