Re: Mini improvement: statement_cost_limit
От | Decibel! |
---|---|
Тема | Re: Mini improvement: statement_cost_limit |
Дата | |
Msg-id | 7A2B9A3E-00FC-4E06-A491-6C6FC30DCCAD@decibel.org обсуждение исходный текст |
Ответ на | Re: Mini improvement: statement_cost_limit (Robert Treat <xzilla@users.sourceforge.net>) |
Список | 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 по дате отправления: