Re: poor performance when recreating constraints on large tables

On Wed, Jun 8, 2011 at 10:57 PM, Greg Smith <greg(at)2ndquadrant(dot)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.