On Fri, May 18, 2007 at 03:26:08PM -0700, Abu Mushayeed wrote:
> Also, this query ran today and it already finished. Today it was
> IO intensive.
Are you entirely sure that it's not a coincidence, and something
_else_ in the system is causing the CPU issues?
A
--
Andrew Sullivan | [EMAIL
On Sat, May 19, 2007 at 12:32:33AM +0200, Steinar H. Gunderson wrote:
> Did you ANALYZE your tables recently? If the joins are really between
> millions of rows and the planner thinks it's a couple thousands, the stats
> sound rather off...
Sorry, I forgot your first e-mail where you said you had
On Fri, May 18, 2007 at 02:37:27PM -0700, Abu Mushayeed wrote:
>>> set enable_nestloop = off;
>> What's the rationale for this?
> To eliminate nested loop. It does a nested loop betwwen to very large
> table(millions of rows).
If the planner chooses a nested loop, it is because it believes it is
> one of them has suddenly decided to get very slow
Is there a way to predict when the system will do this? Also, why would it
suddenly go from IO intensive to CPU intensive.
Also, this query ran today and it already finished. Today it was IO intensive.
Please provide me some dir
Abu Mushayeed <[EMAIL PROTECTED]> writes:
> The query is as follows and it's explain plan is also attached:
The query itself seems to be a simple join over not too many rows, so
I don't see how it could be taking 24 hours. What I suspect is you're
incurring lots and lots of invocations of those
What Postgres version is this?
8.1.3
> set enable_nestloop = off;
What's the rationale for this?
To eliminate nested loop. It does a nested loop betwwen to very large
table(millions of rows).
> HashAggregate (cost=152555.97..152567.32 rows=267 width=162)
152000 disk page fetch
On Fri, May 18, 2007 at 09:02:52AM -0700, Abu Mushayeed wrote:
> I have an interesting problem. I have the following query that ran ok on
> Monday and Tuesday and it has been running ok since I have been at this
> job. I have seen it to be IO intensive, but since Wednesday it has become
> CPU inten
I have an interesting problem. I have the following query that ran ok on Monday
and Tuesday and it has been running ok since I have been at this job. I have
seen it to be IO intensive, but since Wednesday it has become CPU intensive.
Database wise fresh data has been put into the tables, vacuume
