Re: poor performance when recreating constraints on large tables

Поиск
Список
Период
Сортировка
От Samuel Gendler
Тема Re: poor performance when recreating constraints on large tables
Дата
Msg-id BANLkTi=298_0XSF4covs04cJGdUFEX-gCw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: poor performance when recreating constraints on large tables  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-performance


On Wed, Jun 8, 2011 at 10:57 PM, Greg Smith <greg@2ndquadrant.com> wrote:
Samuel Gendler wrote:
Sure, but if it is a query that is slow enough for a time estimate to be useful, odds are good that stats that are that far out of whack would actually be interesting to whoever is looking at the time estimate, so showing some kind of 'N/A' response once things have gotten out of whack wouldn't be unwarranted.

The next question is what are you then going to do with that information?

The ability to track some measure of "progress" relative to expectations is mainly proposed as something helpful when a query has gone out of control.  When that's happened, the progress meter normally turns out to be fundamentally broken; the plan isn't happening at all as expected.  So, as you say, you will get an "N/A" response that says the query is out of control, when in the cases where this sort of thing is expected to be the most useful.

Well, in my case, the use I'd put it to is a query that is necessarily long running (aggregations over large quantities of data that take a minute or two to complete), and the stats are accurate enough that it would potentially let me show a progress meter of some kind in the few places where such queries are run interactively rather than on a schedule.  Not that I'm really thinking seriously about doing so, but there are places in code I maintain where such a thing could prove useful if its accuracy is reasonable for the queries in question.  ENough to at least toy with the suggested sequence method and see what happens when I've got some spare time to play.
 

В списке pgsql-performance по дате отправления:

Предыдущее
От: Willy-Bas Loos
Дата:
Сообщение: Re: [PERFORMANCE] expanding to SAN: which portion best to move
Следующее
От: Jochen Erwied
Дата:
Сообщение: Re: Postgresql on itanium server