| From: | Kyle Cordes <kyle(at)kylecordes(dot)com> | 
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org | 
| Subject: | Re: 8.1 count(*) distinct: IndexScan/SeqScan | 
| Date: | 2005-11-25 03:15:44 | 
| Message-ID: | 438681E0.6070006@kylecordes.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
Tom Lane wrote:
>What "same result"?  You only ran it up to 2K rows, not 2M.  In any
>case, EXPLAIN without ANALYZE is pretty poor ammunition for complaining
>that the planner made the wrong choice.  I ran the same 
>
Hello, sorry to jump in mid-stream, but this reminded me of something.
I have hit cases where I have a query for which there is a somewhat 
"obvious" (to a human...) query plan that should make it possible to get 
a query answer pretty quickly.  Yet the query "never" finishes (or 
rather, after hours of waiting I finally kill it).  I assume this is 
because of a sub-optimal query plan.  But, it appears that an EXPLAIN 
ANALYZE runs the actual query, so it takes as long as the actual query.
In such a case, how can I go about tracking down the issue, up to an 
including a complaint about the query planner?   :-)
(Overall, I'm pretty pleased with the PG query planner; it often gets 
better results than another, popular commercial DBMS we use here.... 
that is just a general impression, not the result of setting up the same 
schema in each for a comparison.)
Kyle Cordes
www.kylecordes.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vipul.Gupta | 2005-11-25 04:48:17 | Re: xlog flush request error | 
| Previous Message | Tom Lane | 2005-11-25 02:37:53 | Re: 8.1 count(*) distinct: IndexScan/SeqScan |