Re: Slow performance after restoring a dump
От | Tom Lane |
---|---|
Тема | Re: Slow performance after restoring a dump |
Дата | |
Msg-id | 1565.1521476520@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Slow performance after restoring a dump (David Osborne <david@qcode.co.uk>) |
Ответы |
Re: Slow performance after restoring a dump
|
Список | pgsql-performance |
David Osborne <david@qcode.co.uk> writes: > Hi, yes I've run "analyse" against the newly restored database. Should that > be enough? My apologies, you did say that further down in the original message. It looks like the core of the problem is the poor rowcount estimation here: -> Bitmap Index Scan on stock_trans_product_idx (cost=0.00..31.42 rows=1465 width=0) (actual time=0.009..0.009rows=0 loops=1) Index Cond: (product_id = 2466420) Buffers: shared hit=3 You might be able to improve that by raising the statistics target for stock_trans.product_id. I'm not sure why you weren't getting bitten by the same issue in 9.1; but the cost estimates aren't that far apart for the two plans, so maybe you were just lucky ... regards, tom lane
В списке pgsql-performance по дате отправления: