public inbox for pgsql-admin@postgresql.org
help / color / mirror / Atom feedFrom: Ron Johnson <ronljohnsonjr@gmail.com>
To: Raj <rajeshkumar.dba09@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: Re: Slowness
Date: Mon, 13 Apr 2026 15:04:54 -0400
Message-ID: <CANzqJaA8GpURz3fAKhnpXLQvOguhwBAyacvCK1-wdkFGP0Nh0w@mail.gmail.com> (raw)
In-Reply-To: <CAJk5AtZ1-N4hs=6D1NtnNNt116e9kjEhpFdakrkJUJtgaL_xKQ@mail.gmail.com>
References: <CAJk5AtZvkEdQsGLOEBAXuFv085End7H2T7SGkaEfTO1+QEARPw@mail.gmail.com>
<2fd0442020d5b23609873f999b7d374875875689.camel@cybertec.at>
<CAJk5AtZ_7nKTLpVvduJCeVD=qMD=A9nVia=UmCWGo6JkbRMoRQ@mail.gmail.com>
<efb70f15e61eaa95bcfa6039f6dd086481fc4bdb.camel@cybertec.at>
<CAJk5AtZ1-N4hs=6D1NtnNNt116e9kjEhpFdakrkJUJtgaL_xKQ@mail.gmail.com>
I'd:
1. enable log_min_duration_statement,
2. capture pg_stat_user_indexes,
3. tune autovacuum vacuum and analyze threshold values (the defaults are in
my experience way too high),
4. query pg_stat_user_tables joined to pg_class to see which tables need
more manual vacuuming and/or analyzing, and
5. check effective_cache_size, shared_buffers, work_mem and
maintenance_work_mem to see if they're set to Best Practice values.
On Mon, Apr 13, 2026 at 1:44 PM Raj <rajeshkumar.dba09@gmail.com> wrote:
> Ok great. If I start with normal health check top, free -h, patronictl
> list, and all status of components such as etcd, haproxy etcd pgnouncer ,
> then stat user tables, pgstatactivity, pgstatstatements and error log.
> Apart from this, what dba should do?
>
> On Mon, 13 Apr 2026, 22:45 Laurenz Albe, <laurenz.albe@cybertec.at> wrote:
>
>> On Mon, 2026-04-13 at 22:05 +0530, Raj wrote:
>> > On Mon, 13 Apr 2026, 18:32 Laurenz Albe, <laurenz.albe@cybertec.at>
>> wrote:
>> > > On Mon, 2026-04-13 at 18:25 +0530, Raj wrote:
>> > > > When customer says they are facing slowness, what all wee need to
>> check in
>> > > > postgres db with 3 node patroni set up (sync between 1 and 2) -
>> async with dr.
>> > > >
>> > > > We recently migrated from oracle to postgres..vacuum analyze is
>> done.
>> > > >
>> > > > How to check this during the time slowness faced and also after
>> couple of hrs of issue window.
>> > > >
>> > > > Should we start with pgstatstatements and logs or how is it.
>> Help.me hight level what all I need to check
>> > >
>> > > You have to figure out *what exactly* is slow. The customer has to
>> tell you which
>> > > statements are slow. The parameter "log_min_duratoin_statement" might
>> help.
>> > >
>> > > Then you have to tune those statements.
>> >
>> > How long min duration statement is decided. Is it dba who decide how
>> much needs to be set?
>>
>> Sorry, I made a typo. It is a database parameter and called
>> "log_min_duration_statement".
>>
>> Your questions seem to indicate that you have almost no knowledge about
>> PostgreSQL.
>> Without database knowledge, it is impossible to find slow statements, let
>> alone tune
>> them. Perhaps you should spend some time with the PostgreSQL
>> documentation or hire
>> a consultant.
>>
>> Yours,
>> Laurenz Albe
>>
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: ronljohnsonjr@gmail.com, rajeshkumar.dba09@gmail.com, laurenz.albe@cybertec.at, pgsql-admin@lists.postgresql.org
Subject: Re: Slowness
In-Reply-To: <CANzqJaA8GpURz3fAKhnpXLQvOguhwBAyacvCK1-wdkFGP0Nh0w@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox