From: | Jeff <threshar(at)torgo(dot)978(dot)org> |
---|---|
To: | "Shoaib Burq (VPAC)" <sab(at)vpac(dot)org> |
Cc: | performance pgsql <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: two queries and dual cpu (perplexed) |
Date: | 2005-04-22 11:48:29 |
Message-ID: | ec08c6c467efe0132625ea1a80a20561@torgo.978.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Apr 21, 2005, at 11:33 PM, Shoaib Burq (VPAC) wrote:
>
> BTW I guess should mention that I am doing the select count(*) on a
> View.
>
A bit of a silly question...
but are you actually selecting all the rows from this query in
production or would it be more selective? ie select * from bigslowview
where bah = 'snort'?
> Ran the Explain analyse with the nestedloop disabled but it was taking
> forever... and killed it after 30mins.
>
If it takes too long you can run just plain explain (no analyze) and it
will show you the plan. This is nearly always instant... it'll give
you a clue as to if your setting changes did anything.
You may need to end up breaking some parts of this up into subqueries.
I've had to do this before. I had one query that just ran too dang
slow as a join so I modified it into a subquery type deal. Worked
great. However since you are selecting ALL rows I doubt that will help
much.
Another option may be to use materialized views. Not sure how
"dynamic" your data model is. It could help.
--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-22 14:06:33 | Re: Index bloat problem? |
Previous Message | Dawid Kuroczko | 2005-04-22 10:15:24 | Re: immutable functions vs. join for lookups ? |