t_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 wrote:
> David Osborne writes:
> > H
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 tak
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
