Re: Slow performance after restoring a dump

Поиск
Список
Период
Сортировка
От David Osborne
Тема Re: Slow performance after restoring a dump
Дата
Msg-id CAKmpXCfJttx75n+qL_RCZpmWvNq9CdfkzMgoWdccu89dqOSxLw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow performance after restoring a dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Дерево обсуждения
That did the trick... thanks!  
yes perhaps a minor planner difference just tipped us over the edge previously

=> alter table stock_trans alter column product_id set STATISTICS 1000;

                                                                          QUERY PLAN                    
--------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=3461.10..3461.10 rows=1 width=4) (actual time=0.014..0.014 rows=0 loops=1)
   Buffers: shared hit=3
   ->  Sort  (cost=3461.10..3461.75 rows=260 width=4) (actual time=0.013..0.013 rows=0 loops=1)
         Sort Key: a.trans_date DESC
         Sort Method: quicksort  Memory: 25kB
         Buffers: shared hit=3
         ->  Nested Loop  (cost=0.87..3459.80 rows=260 width=4) (actual time=0.008..0.008 rows=0 loops=1)
               Buffers: shared hit=3
               ->  Index Scan using stock_trans_product_idx on stock_trans s  (cost=0.43..1263.55 rows=260 width=4) (actual time=0.007..0.007 rows=0 loops=1)
                     Index Cond: (product_id = 2466420)
                     Filter: (credit_stock_account_id = 3)
                     Buffers: shared hit=3
               ->  Index Scan using account_trans_pkey on account_trans a  (cost=0.43..8.44 rows=1 width=8) (never executed)
                     Index Cond: (account_trans_id = s.account_trans_id)
 Planning time: 0.255 ms
 Execution time: 0.039 ms
(16 rows)




On 19 March 2018 at 16:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.009 rows=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



--
David Osborne
Qcode Software Limited
T: +44 (0)1463 896484

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Slow performance after restoring a dump
Следующее
От: Pavel Suderevsky
Дата:
Сообщение: RE: PG 9.6 Slow inserts with long-lasting LWLocks