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 по дате отправления: