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)
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
>
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
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
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
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
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:
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|
-++-+-+---++--+--+-+
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?
Hi team,
We are seeing unusually high query planning times on our Postgres server. I
am attaching a few query plans.
select upc from store_seller_products where upc in
13 matches
Mail list logo
