Re: BUG #4462: Adding COUNT to query causes massive slowdown
От | Jussi Pakkanen |
---|---|
Тема | Re: BUG #4462: Adding COUNT to query causes massive slowdown |
Дата | |
Msg-id | 42d23b2e0810090751k255cde25iacd131d66069dce1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #4462: Adding COUNT to query causes massive slowdown (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: BUG #4462: Adding COUNT to query causes massive slowdown
|
Список | pgsql-bugs |
On Thu, Oct 9, 2008 at 3:05 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > Jussi Pakkanen wrote: >> >> However when I try to count the amount of distinct codes, I get this: >> >> >> EXPLAIN SELECT COUNT(DISTINCT code) FROM log; >> QUERY PLAN >> >> ---------------------------------------------------------------------------- >> ----- >> Aggregate (cost=100801488.30..100801488.31 rows=1 width=10) >> -> Seq Scan on log (cost=100000000.00..100721245.24 rows=32097224 >> width=10) >> (2 rows) > > This looks like you have one of the enable_${plantype} parameters turned > off. 100000000 is the penalty that is added when a plantype if turned off. This was caused by enable_seqscan. When I set it to 'on', the penalty disappears but it still does the full table scan. Given that PostgreSQL does the scan even with the huge seqscan penalty, I can think of only two different causes: 1) some sort of a bug in the query analyzer 2) SELECT COUNT(DISTINCT x) for some reason requires information that is not available in the index. The only one I could think of would be NULL values, but the 'code' field is defined as 'NOT NULL'. Also I had a small error in my original but report. There are 2 million distinct values of 'code', rather than 200 000.
В списке pgsql-bugs по дате отправления: