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

From Decibel!
Subject Re: Mini improvement: statement_cost_limit
Date
Msg-id 7A2B9A3E-00FC-4E06-A491-6C6FC30DCCAD@decibel.org
Whole thread Raw
In response to Re: Mini improvement: statement_cost_limit  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
On Aug 3, 2008, at 9:57 PM, Robert Treat wrote:
>>> 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 should have an approved API for dumping stats from one database  
and loading them into another. pg_dump needs this as well, IMO.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828



pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: Visibility Groups
Next
From: Decibel!
Date:
Subject: Re: Mini improvement: statement_cost_limit