| 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: | Whole Thread | Raw Message | 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 ? |