Michael, thanks for your answer.
Looks like it is not my case because issue is reproducible also for table with
100% single writer backend. Also as it was mentioned whole system gets hung.
Regards,
Pavel Suderevsky
From: MichaelDBA
Sent: Friday, March 16, 2018 16:42
To: Pavel Suderevsky
Cc: pg
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
David Osborne 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
Hi, yes I've run "analyse" against the newly restored database. Should that
be enough?
On 19 March 2018 at 15:35, Tom Lane wrote:
> David Osborne writes:
>
> The first question people will ask is did you re-ANALYZE the new
> database? pg_dump doesn't take care of that for you, and auto-analyze
David Osborne writes:
> Hi, I was wondering if someone could help us work out why this query is so
> slow.
> We've just dumped a database (Postgresql 9.1) and restored it to a new
> instance (AWS RDS 9.6) (via pg_dump, restored to psql)
The first question people will ask is did you re-ANALYZE the
Hi, I was wondering if someone could help us work out why this query is so
slow.
We've just dumped a database (Postgresql 9.1) and restored it to a new
instance (AWS RDS 9.6) (via pg_dump, restored to psql)
We immediately see that the following fairly straightforward query is now
extremely slow w
