Re: bad plan: 8.4.8, hashagg, work_mem=1MB.
От
Jon Nelson
Тема
Re: bad plan: 8.4.8, hashagg, work_mem=1MB.
Дата
Msg-id
BANLkTike3P_0RSd--dZBcAZ+MKcy3ieDqQ@mail.gmail.com
Ответ на
Re: bad plan: 8.4.8, hashagg, work_mem=1MB. (Tom Lane)
Список
Дерево обсуждения
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. Tom Lane <tgl@sss.pgh.pa.us>
Re: 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. Robert Haas <robertmhaas@gmail.com>
On Mon, Jun 20, 2011 at 11:08 AM, Tom Lane wrote: > Jon Nelson 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. What sorts of details would you like? The row count for the Result line is approximately correct -- the stats for all tables are up to date (the tables never change after import). statistics is set at 100 currently. -- Jon
В списке pgsql-performance по дате отправления
От: Sushant Sinha
Дата: