On Fri, 2024-03-15 at 00:31 +0530, hassan rafi wrote:
> We have migrated to postgres version 16.1, but still due to very high update
> activity on our DB, we are seeing elevated response times, though now the
> planning time is less.
>
> catalog-v2=> explain (analyze, verbose, settings, buffers) S
On Fri, 15 Mar 2024 at 08:01, hassan rafi wrote:
> We have migrated to postgres version 16.1, but still due to very high update
> activity on our DB, we are seeing elevated response times, though now the
> planning time is less.
>Buffers: shared hit=33359 read=6590 dirtied=9379
> Executio
We have migrated to postgres version 16.1, but still due to very high
update activity on our DB, we are seeing elevated response times, though
now the planning time is less.
catalog-v2=> explain (analyze, verbose, settings, buffers) SELECT
products_inventory_delta.upc FROM products_inventory_delta
Thanks all. Will try upgrading the postgres version.
On Sun, Mar 10, 2024 at 11:44 PM Ron Johnson
wrote:
> On Sun, Mar 10, 2024 at 1:34 PM Greg Sabino Mullane
> wrote:
>
>>
>> On Sat, Mar 9, 2024 at 1:57 PM hassan rafi
>> wrote:
>>
>>> Would upgrading to the latest version of Postgres potentia
On Sun, Mar 10, 2024 at 1:34 PM Greg Sabino Mullane
wrote:
>
> On Sat, Mar 9, 2024 at 1:57 PM hassan rafi
> wrote:
>
>> Would upgrading to the latest version of Postgres potentially solve the
>> issue?
>>
>
> Potentially, yes, but the only one who can answer that for sure is you.
> Upgrade to 11
On Sat, Mar 9, 2024 at 1:57 PM hassan rafi wrote:
> Would upgrading to the latest version of Postgres potentially solve the
> issue?
>
Potentially, yes, but the only one who can answer that for sure is you.
Upgrade to 11.22 and re-run the query. Worst case scenario, it runs the
same speed but yo
Thanks,
Would upgrading to the latest version of Postgres potentially solve the
issue?
On Sat, Mar 9, 2024 at 11:30 PM Tom Lane wrote:
> hassan rafi writes:
> > The issue of high query planning time seems to intermittently resolve
> > itself, only to reoccur after a few hours.
>
> I wonder if
hassan rafi writes:
> The issue of high query planning time seems to intermittently resolve
> itself, only to reoccur after a few hours.
I wonder if you are running into the lack of this fix:
Author: Tom Lane
Branch: master Release: REL_16_BR [9c6ad5eaa] 2022-11-22 14:40:20 -0500
Branch: REL_15
Sure, we will plan to upgrade to the latest version.
schemaname|relname |n_tup_ins|n_tup_upd
|n_tup_del|n_live_tup|n_dead_tup|last_vacuum|last_autovacuum |
--++-+--+-+--+--+---+
It'd be worth checking that your default_statistics_target isn't set
to anything wild, but beyond that, it'd be interesting to look at the
output of vacuum verbose on some of the system catalogs as istm you
might have catalog bloat.
I should also mention that you're running a non-longer-supported
Postgres version: PostgreSQL 11.18, compiled by Visual C++ build 1800,
64-bit
relname
|relpages|reltuples|relallvisible|relkind|relnatts|relhassubclass|reloptions|pg_table_size|
-++-+-+---++--+--+-+
store_
On Sat, Mar 9, 2024 at 7:18 AM hassan rafi wrote:
> Hi team,
>
> We are seeing unusually high query planning times on our Postgres server.
> I am attaching a few query plans.
>
Postgresql version number?
Rows in the tables?
System load?
12 matches
Mail list logo
