On Mon, 2025-04-07 at 20:25 +0100, Simon Windsor wrote:
> We used pg_dump|pg_restore to migrate the data.
>
> The full explain plan is at https://explain.depesz.com/s/742M. The SQL
>
> explain (analyze, buffers) select count(*) from consignments where
> (req_status_tstamp >= '2025-03-28 00:00'::
On Mon, 2025-04-07 at 15:48 +0100, Simon Windsor wrote:
> After upgrading a Db from Pg13 (Centos) to Pg16(Ubuntu) some queries
> on a simple, large table (200M rows) are very slow
If you used "pg_upgrade", did you ANALYZE the database?
If that is not the problem, we can't guess what your problem
On 4/7/25 12:25, Simon Windsor wrote:
Hi
We used pg_dump|pg_restore to migrate the data.
Did you do an ANALYZE on the Postgres 16 instance after the pg_restore?
The full explain plan is at https://explain.depesz.com/s/742M. The SQL
explain (analyze, buffers) select count(*) from consignmen
Hi
We used pg_dump|pg_restore to migrate the data.
The full explain plan is at https://explain.depesz.com/s/742M. The SQL
explain (analyze, buffers) select count(*) from consignments where
(req_status_tstamp >= '2025-03-28 00:00'::timestamp and
req_status_tstamp <= '2025-03-28 01:00'::timesta
Hello
After upgrading a Db from Pg13 (Centos) to Pg16(Ubuntu) some queries on
a simple, large table (200M rows) are very slow
id integer not null
status char(4) not null
status_tstamp timestamp
<... other columns ...>
If I create indexes on
* status, status_tstamp
* status_tstamp when stat
