Re: bad plan: 8.4.8, hashagg, work_mem=1MB.
| От | Tom Lane |
|---|---|
| Тема | Re: bad plan: 8.4.8, hashagg, work_mem=1MB. |
| Дата | |
| Msg-id | 6961.1308586099@sss.pgh.pa.us обсуждение |
| Ответ на | bad plan: 8.4.8, hashagg, work_mem=1MB. (Jon Nelson <jnelson+pgsql@jamponi.net>) |
| Ответы |
Re: bad plan: 8.4.8, hashagg, work_mem=1MB.
|
| Список | pgsql-performance |
Jon Nelson <jnelson+pgsql@jamponi.net> writes:
> I ran a query recently where the result was very large. The outer-most
> part of the query looked like this:
> HashAggregate (cost=56886512.96..56886514.96 rows=200 width=30)
> -> Result (cost=0.00..50842760.97 rows=2417500797 width=30)
> The row count for 'Result' is in the right ballpark, but why does
> HashAggregate think that it can turn 2 *billion* rows of strings (an
> average of 30 bytes long) into only 200?
200 is the default assumption about number of groups when it's unable to
make any statistics-based estimate. You haven't shown us any details so
it's hard to say more than that.
regards, tom lane
В списке pgsql-performance по дате отправления: