Re: 8.1 count(*) distinct: IndexScan/SeqScan
| От | Kyle Cordes | 
|---|---|
| Тема | Re: 8.1 count(*) distinct: IndexScan/SeqScan | 
| Дата | |
| Msg-id | 438681E0.6070006@kylecordes.com обсуждение исходный текст  | 
		
| Ответ на | Re: 8.1 count(*) distinct: IndexScan/SeqScan (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | 
                	
            		Re: 8.1 count(*) distinct: IndexScan/SeqScan
            		
            		 | 
		
| Список | 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
В списке pgsql-performance по дате отправления: