Re: Slow performance after restoring a dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Osborne <david(at)qcode(dot)co(dot)uk>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow performance after restoring a dump
Date: 2018-03-19 16:22:00
Message-ID: 1565.1521476520@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message David Osborne 2018-03-19 16:33:26 Re: Slow performance after restoring a dump
Previous Message David Osborne 2018-03-19 15:43:47 Re: Slow performance after restoring a dump