Re: poor performance when recreating constraints on large tables - Mailing list pgsql-performance

From Samuel Gendler
Subject Re: poor performance when recreating constraints on large tables
Date
Msg-id BANLkTi=298_0XSF4covs04cJGdUFEX-gCw@mail.gmail.com
Whole thread Raw
In response to Re: poor performance when recreating constraints on large tables  (Greg Smith <greg@2ndquadrant.com>)
List 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 by date:

Previous
From: Willy-Bas Loos
Date:
Subject: Re: [PERFORMANCE] expanding to SAN: which portion best to move
Next
From: Jochen Erwied
Date:
Subject: Re: Postgresql on itanium server