Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wCKoo-001sns-1l for pgsql-admin@arkaria.postgresql.org; Mon, 13 Apr 2026 17:11:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wCKok-0081p6-2r for pgsql-admin@arkaria.postgresql.org; Mon, 13 Apr 2026 17:11:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wCKok-0081ox-1c for pgsql-admin@lists.postgresql.org; Mon, 13 Apr 2026 17:11:23 +0000 Received: from mail-oo1-xc2e.google.com ([2607:f8b0:4864:20::c2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wCKoj-00000000sBy-1BEt for pgsql-admin@lists.postgresql.org; Mon, 13 Apr 2026 17:11:23 +0000 Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-662f30d3f1fso2631814eaf.1 for ; Mon, 13 Apr 2026 10:11:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776100278; cv=none; d=google.com; s=arc-20240605; b=hY7sEQY6WhGHLdBIh0n4RzzSXVdTWJok6uGV+z1fVX6L558yE19/Gg9JrVVY5KBCp3 ZB7cLRMJYWwn9ccwzVI2jDOMOgOUqyaBUdhq1SHwZgoQrtuT6B3MucrODMFvGVimZtY0 LMCGmJbANQ8kHEYn7dKY1m7irtakBNLlknmZGfLOY/QiKNwxemY1B5HtDEnHcF5BSQme JK6egtrz7bMwlxAGphPGBYWmuCdD3aIZLaSUHj5nEOKFvexdV2VR9vkA5ow+GonjZ13f FzPEI8T5+NZrffxvLUPykhq4xXF69WNTW+vyvNOPl/aJTWGbOS2HdYSu8KFg/IiJcvxm KCog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=QYgOuQZf+O1gne3CcWwr6Pu8ws4HAU5+nAKwEjM8w8g=; fh=druxZHa2fk4e6MLibibygn9AWWgeaAPo4m8Gpo2MBXU=; b=Rq97hbLvrRSBW/1yB4GreRGrjxWUSrL04TuvftdDbDUd4c6Ljr0/PkJnZ2cuAcSSgj 0BWU90/yPbhQim4WTo/S316etTKQ7ihkkU4JDm9dOMJcjMIrnrwFbohQpDuXpFkpVpnk hSI9NIGnHBsK+D5nXOR67UfrMi/1D65bQGEe9DFn1NYL1Pmd+adzn3KW3/fbNEUggcNJ IyUexshcrdtKyGiA0oAMuSP2HUIowsro5OYnunsPPBHi91QyGoM5rLVBUnfwfSOg+m2Q 0UBN1cCRqYA5z1F3sLShp5qySsdZ01kc9fP5IFF3GeYPREIV2QOui0TmrUCFZ2t/YZnq 5iAw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776100278; x=1776705078; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=QYgOuQZf+O1gne3CcWwr6Pu8ws4HAU5+nAKwEjM8w8g=; b=gRKyDVjEghAmoPy7tF9yNg70CkgmkbxfbvjazAJOkcT6Ge6MEZyA/qoJMFELJmzx6q i0Kmt5DOQQTKYwZqbETIH6YC6dwJhDFwfAyHWH0ORQ1OB5M+l4smu61RhRHEjrW524FY HgOzGt+Qfj103HX4rem0NUehxknG++SOrC1jR2qndSNaX2xt+wOAS5jWW9VBvyNH3duU t+f/dndJACKKjJ+dE1HabAgXx5RCdqpNQRrlQ0v8GPScRitpn8Io/0OyD1S3DUp1cmNi sL7YtoxNnZ47VCYwLHp3CpoRDTIzF88cMyV8mteQTwNptLthtA4mzWZQ5f+giSQR0MRn S8Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776100278; x=1776705078; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QYgOuQZf+O1gne3CcWwr6Pu8ws4HAU5+nAKwEjM8w8g=; b=EqRisS6quQedOPr5KL1VXmwDD/2EN22cywIp8eHb2hnnYFLAdZWiODkXrVQXa6YHvE O+bKYzCJ9tXYk9TY56Yt5jVS3rRHyX74XOkQxEQ0OYlRSNcJ7PDsd1pN9mZR6N89IzcS fnw3MBvj/FVGn/gIcLkfhRfPUcHFoHSHmV1Xsmtrc6xoyzfLbzTyrIosvIgVYxGbwxkc yCAz3wE5YsVrq/Tsbhm2zSa6oVSnPz2rwggqxmo3OjCvpm3SP+IoodsMEccaWwxZBrfB l9VLZH2MuPTDh6lK8kSuxR7eck4M4OR1G7LbIPP3v0TEYaRX22gcQrYA/Cvu20/Ouz0o zpWg== X-Gm-Message-State: AOJu0Yy1vEgIZtir4AqXD04ZriTYIlVzx/y26jKX7vuRtE1+ECmY4hvE kbgWjg52I4EZoEL0EZm7Aa6dyZtOuBxAS4yHXDspIwEBnem6UVaP8kU0H/K+c1J/dVQd6A9aVwe xZHIEqvNnHJcAMwQUs0O1gPQkNFF181v3AjH8 X-Gm-Gg: AeBDieuO8K5bqdyWC+t5L45yKInmdeKOn6jC/UDjEj9ctLNLP/zoQoOFJf0YJz56RQS Hokj4t4DcXjvR5FcnADE8jv9a0N/M0DP4Ybwvg4DithxuQZn3pQ2vKORuqR3VFiy2KIjKFxGW6h GaQxDhtMVN2YbEGha8OD+EWVpHFKmgOjLKXI+Ief7SwlFvwWQrIdzpK6etuJvHa4NoWUIK+wHqG YmKa5v2gUrSEMVHoK0YUmzRLIhBGnXZmYHAmXl9udUF68OE+dPJriUlI4ckYw5yWw20w/PeQTsE +uV8rE8K X-Received: by 2002:a05:6820:1505:b0:683:310:77c0 with SMTP id 006d021491bc7-68bf83c8996mr5804984eaf.23.1776100277845; Mon, 13 Apr 2026 10:11:17 -0700 (PDT) MIME-Version: 1.0 References: <2fd0442020d5b23609873f999b7d374875875689.camel@cybertec.at> In-Reply-To: From: Ron Johnson Date: Mon, 13 Apr 2026 13:11:06 -0400 X-Gm-Features: AQROBzBcfgaMqmh1qrKoxzxe7V0_CRCqmF7pNtKLS0gPnc_7Shcy1v4hRcm0Pjo Message-ID: Subject: Re: Slowness To: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000258093064f5a9266" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000258093064f5a9266 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "All the stakeholders" decide the threshold. For example, if *they* complain about queries taking more than 2 seconds, you obviously shouldn't set log_min_duratoin_statement to 5 seconds. If they don't know, are too clueless to know, or it's a mixed OLTP & reporting database, pick a reasonable value and go from there. You can always change it later... On Mon, Apr 13, 2026 at 12:36=E2=80=AFPM Raj = wrote: > How long min duration statement is decided. Is it dba who decide how much > needs to be set? > > On Mon, 13 Apr 2026, 18:32 Laurenz Albe, wrote= : > >> On Mon, 2026-04-13 at 18:25 +0530, Raj wrote: >> > When customer says they are facing slowness, what all wee need to chec= k >> 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. >> >> Yours, >> Laurenz Albe >> > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000258093064f5a9266 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"All the stakeholders" decide the threshold= .=C2=A0 For example, if they complain about queries taking more than= 2 seconds, you obviously shouldn't set log_min_duratoin_statement to 5= seconds.

If they don't know, are too clueless= to know, or it's a mixed OLTP & reporting database, pick a reasona= ble value and go from there.

You can always change= it later...=C2=A0

On Mon, Apr 13, 2026 at 12:36=E2=80= =AFPM Raj <rajeshkumar.db= a09@gmail.com> wrote:
How long min duration statement is decided. = Is it dba who decide how much needs to be set?=C2=A0

On Mon, 13 Apr 2026, 18= :32 Laurenz Albe, <laurenz.albe@cybertec.at> wrote:
On Mon, 2026-04-13 at 18:25 +0530, Raj wro= te:
> When customer says they are facing slowness, what all wee need to chec= k 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.<= br> >
> 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 h= ight level what all I need to check

You have to figure out *what exactly* is slow.=C2=A0 The customer has to te= ll you which
statements are slow. The parameter "log_min_duratoin_statement" m= ight help.

Then you have to tune those statements.

Yours,
Laurenz Albe


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000258093064f5a9266--