Re: Slow performance after restoring a dump

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Osborne <david(at)qcode(dot)co(dot)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
http://www.qcode.co.uk
T: +44 (0)1463 896484