On Wed, Jun 8, 2011 at 10:57 PM, Greg Smith 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,
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
gotte
-- Forwarded message --
From: Claudio Freire
Date: Wed, Jun 8, 2011 at 11:57 PM
Subject: Re: [PERFORM] poor performance when recreating constraints on
large tables
To: Samuel Gendler
On Wed, Jun 8, 2011 at 9:57 PM, Samuel Gendler
wrote:
> Sure, but if it is a query that
On Wed, Jun 8, 2011 at 12:53 PM, Kevin Grittner wrote:
> Samuel Gendler wrote:
>
> > The planner knows how many rows are expected for each step of the
> > query plan, so it would be theoretically possible to compute how
> > far along it is in processing a query based on those estimates,
> > woul
Samuel Gendler wrote:
> The planner knows how many rows are expected for each step of the
> query plan, so it would be theoretically possible to compute how
> far along it is in processing a query based on those estimates,
> wouldn't it?
And it is sometimes off by orders of magnitude. How muc
On Wed, Jun 8, 2011 at 12:28 PM, Robert Haas wrote:
> On Mon, Jun 6, 2011 at 6:10 PM, Mike Broers wrote:
> > Thanks for the suggestion, maintenance_work_mem is set to the default of
> > 16MB on the host that was taking over an hour as well as on the host that
> > was taking less than 10 minutes.
On Mon, Jun 6, 2011 at 6:10 PM, Mike Broers wrote:
> Thanks for the suggestion, maintenance_work_mem is set to the default of
> 16MB on the host that was taking over an hour as well as on the host that
> was taking less than 10 minutes. I tried setting it to 1GB on the faster
> test server and it
Thanks for the suggestion, maintenance_work_mem is set to the default of
16MB on the host that was taking over an hour as well as on the host that
was taking less than 10 minutes. I tried setting it to 1GB on the faster
test server and it reduced the time from around 6-7 minutes to about 3:30.
th
Mike Broers writes:
> I am in the process of implementing cascade on delete constraints
> retroactively on rather large tables so I can cleanly remove deprecated
> data. The problem is recreating some foreign key constraints on tables of
> 55 million rows+ was taking much longer than the maintena
I originally posted this on admin, but it was suggested to post it to
performance so here goes -
I am in the process of implementing cascade on delete constraints
retroactively on rather large tables so I can cleanly remove deprecated
data. The problem is recreating some foreign key constraints o
10 matches
Mail list logo
