Re: poor performance when recreating constraints on large tables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Jun 8, 2011 at 10:57 PM, Greg Smith <greg@xxxxxxxxxxxxxxx> 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.
 


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux