From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Osborne <david@qcode.co.uk>
Cc: pgsql-performance@postgresql.org
Subject: Re: Slow performance after restoring a dump
Date: Mon, 19 Mar 2018 12:22:00 -0400
Message-ID: <1565.1521476520@sss.pgh.pa.us> (raw)
In-Reply-To: <CAKmpXCduMKf=iO=YjKQcKgfd9V4jS-aKD_JJfvMTYEhQOv6ASQ@mail.gmail.com>
References: <CAKmpXCfZUyTwOT3m0HF+uAGbjHt9GHHvhP4jty6QJQLU4Ag8Dw@mail.gmail.com>
<31890.1521473700@sss.pgh.pa.us>
<CAKmpXCduMKf=iO=YjKQcKgfd9V4jS-aKD_JJfvMTYEhQOv6ASQ@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, david@qcode.co.uk
Subject: Re: Slow performance after restoring a dump
In-Reply-To: <1565.1521476520@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox