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 1wBaBZ-001CD8-0v for pgsql-admin@arkaria.postgresql.org; Sat, 11 Apr 2026 15:23:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wBaAW-00Gnoo-3A for pgsql-admin@arkaria.postgresql.org; Sat, 11 Apr 2026 15:22:45 +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 1wBaAW-00Gnof-1h for pgsql-admin@lists.postgresql.org; Sat, 11 Apr 2026 15:22:45 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wBaAU-00000000X1A-3gn3 for pgsql-admin@lists.postgresql.org; Sat, 11 Apr 2026 15:22:44 +0000 Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-35da9c0c007so2904557a91.2 for ; Sat, 11 Apr 2026 08:22:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775920960; cv=none; d=google.com; s=arc-20240605; b=Jmtt3LlyOeabP3jKTMd9u/GWBrCn7nuebVpK5zlatZT3V+ZzoTds7/3vP9ffu4xTCX ba0ic4VzIeKuPtzRjddxUtprXyQ7lmalE7YpYJmLP9QOU7joeINWBFQTFhZeweS3btbq Yoe+pOUKALtgCea9yiHSHx5spFTdj67LtWEyjwoPaumypZSpLWUo78s8+idyeRJAcxuT 4GJwmArIpdjHjGweIf/OW3QOT1vTQ30YalrMW9xeh4juLK5rY45LVT33jdN0iOFDbpM1 f3sU/velMdc1Y3y8A4Y9OsrkjrbwgX0PVa5ixnXjML8DjvrB+fqc/llEy3EYyraqfhTp UdGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=IMGsWfLkdkCZd5X9F3J2Ft3A/KWzEmlAdKWtixHnC34=; fh=YVqAsyQLaqkSOJ1zvqJdlUnoB6bSkwHNHq4/MX0Vk/s=; b=RPwHHV20F6R/8x8kDSnoqYOU/jd+A1WDTjnZoSh7siDzrwj27r+lM5OjGZPbDFz5jT fAel4oijKO5JmhT8GUHnUmcbbqtRgb1VR8flSqVEUjdAeaQnJDsD2zKQORNowOoc9B4i P53r48bcqPgqIt3XaEZ0ml/uR+eLXv4oYpAn4gJlwWTiZiBs6NeH5/vCWg7/1hjhUScZ iAzODQ8gcuGiBc8026sUyWQNh6gf77P5yPblLy0XAmGa+Ryk0Uf13PDt80tu1MpEaBmJ bqJanto69+IoLtH1ZxFFQlaZRsp8LBFi5QP7GieBynBoYMMluFinbHRC/p/YIdPtHbKK mz+w==; 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=1775920960; x=1776525760; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IMGsWfLkdkCZd5X9F3J2Ft3A/KWzEmlAdKWtixHnC34=; b=LEYSH4eSVHotCsZZ4MKVK1nvjeRf7FPuo7NlffoxkGRT7LglSWyxXboIsZL4RAPrcH 9NmKfiNL8d8pnEzPb/t2VTbZbdeCnexXurF/y22xWZPFG/h11UqAfYX2MsPqYgiXRuS3 Z2yBAv4coCrhN86GHf/RMcERYUv1yACNvjtvhMWLimMnVRH6PRdbwJ3NqTFYgs1uD55+ xPh2zDPYwQe5nXgcelPPbxgpixFqAd41RExnCQctl8VG4+ArJPZiBwi/fxsCJegTvk2k KsadElLgMUSi9BwORNePtrtDY8ocKXCwqnw/+SVhKREaN/JS6joV3ypbv20cmn2WWZYh eNzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775920960; x=1776525760; h=cc: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=IMGsWfLkdkCZd5X9F3J2Ft3A/KWzEmlAdKWtixHnC34=; b=MkN/EFGIitm8dnSrBTyPUm1ruMUIDm1zF3DOWP4RoZnwmOfX9zjuhuO8H39ww58vbw TahvFJ/vMENjn8iPa25rh9uYyJojVlqWxFkrj8TFgEP0650RCxP+Gxlo9ZsJG49Iq6bn yGJ9N47t9md6vePY7/UsJFYnJlfJB/g/LBblJtyzaWad6X9Fuw2DnEcjSjmQ3gN+sDvK GBm9aRS0xaKDHjFyfjJoUb38tPN+GGrmwl8IdLRVav9LURL1BmEXs9iZFtY6IOJf/x9Q 7yuVUtl8tGBtfLJr5o9OHfP5OpK3G6X5yZ+419KECvlg1mbJvNIuWFBiUO8ud7zDhdja phmQ== X-Gm-Message-State: AOJu0YwcGuoeq9nvXZE16GYJDnT1HT2ALQFN8L8P24hVMV1v5ZUWDiSE 8+YoQqj9ud2zRf64un5ziiCMW4YB2QAqU6E2xgTE9p9iJFRQs0pgzB05twCOQ0HPBswY4fvJp7B iEPRkD4yV4M5mknx1MS9xgAGR8XHK7n0= X-Gm-Gg: AeBDievzFo2YklQll7jdF8yZUEFLbsIBCaUfGxqdXrXhy1e1IA+wZeq2VFq7kKmACMC KG7XGlQ0FWUvoDRUHeZCr1ovL3QCuUhZ1GI2G36Falsp4OaAnqneBos/zsBCeQjlcy6Vu3mgm22 wJ290XOVDsk8aU/A5AeiRxwTxDIfLhTlO0BopTHrmqJ6Uex5nhv8YL5DsHULYrUD7+dkvOL/oMy zHdMCX1UK7kU4R/i1Ef5tdtFkPSO6qyNv2K/2nnGuFIlYWhR/16xlvJ68qA7PCnriBTmF+WNZQ/ +5L4K0XFLnQAKa/G5OnD52KFi35gZKHf9qjfEw== X-Received: by 2002:a17:90a:2c85:b0:35e:58d3:329f with SMTP id 98e67ed59e1d1-35e58d335b0mr249066a91.13.1775920959779; Sat, 11 Apr 2026 08:22:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: flatley Date: Sat, 11 Apr 2026 08:22:28 -0700 X-Gm-Features: AQROBzCQ_qd5qemwhuIR5vnAVjgi-StWlfN0Hnn_yVNnmZdD5Bc_06uZj6rAqa4 Message-ID: Subject: Re: Seeking Advice: PostgreSQL Performance Troubleshooting Without Third-Party Tools To: Ron Johnson Cc: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000f4f8da064f30d119" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f4f8da064f30d119 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable this might help - https://github.com/NikolayS/postgres_dba On Fri, Apr 10, 2026 at 11:24=E2=80=AFAM Ron Johnson wrote: > On Fri, Apr 10, 2026 at 1:49=E2=80=AFPM mahamood hussain > wrote: > >> Hi Team, >> >> We are currently working on a migration project from DB2 to PostgreSQL. >> Post-migration, we=E2=80=99re observing several performance issues such = as >> long-running queries and occasional instance crashes. It also appears th= at >> some application-side workloads may not be optimized for PostgreSQL. >> >> From a DBA perspective, I=E2=80=99m looking to proactively identify prob= lem >> areas=E2=80=94such as: >> >> - Long-running queries >> - Jobs/stored procedures consuming high temp space >> - Queries resulting in sequential scans due to missing indexes >> - Lock waits, deadlocks, and memory-heavy operations >> >> We already have key parameters enabled (pg_stat_statements, >> pg_buffercache, etc.), and PostgreSQL is generating logs in .csv format. >> However, the main challenge is efficiently analyzing these logs and >> identifying performance bottlenecks at scale (databases ranging from ~1T= B >> to 15TB). >> >> We currently don=E2=80=99t have third-party monitoring tools like Datado= g, so I=E2=80=99m >> looking for *recommendations on free or lightweight tools* and best >> practices to: >> >> - Parse and analyze PostgreSQL logs (especially CSV logs) >> - Identify top resource-consuming queries and patterns >> - Correlate temp usage, memory pressure, and query behavior >> - Generate actionable insights for the engineering team >> >> Any suggestions on tools, scripts, or approaches that have worked well i= n >> similar large-scale environments would be greatly appreciated. >> > Have you set log_min_duration_statement to some number of milliseconds? > When you do that, the query and its parameters show up in the log file. > Grep for "duration:" to find statements taking longer than *threshold* > milliseconds. > > Does it require some manual effort? Sure. But it's free. > > Barring that, try installing pgbadger. > > -- > Death to , and butter sauce. > Don't boil me, I'm still alive. > lobster! > --000000000000f4f8da064f30d119 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this might help -=C2=A0=C2=A0https://github.com/NikolayS/postgres_dba
<= br>
On Fri, Apr 10, 2026 at 11:24=E2=80=AFAM Ron Johnson <ronljohnsonjr@gmail.com> wr= ote:
On Fri, Apr 10, 2026 at 1:49=E2=80=AFPM mahamood hus= sain <hussain= .ieg@gmail.com> wrote:

Hi Team,

We are currently working on a migration project from DB2 to PostgreSQL. = Post-migration, we=E2=80=99re observing several performance issues such as = long-running queries and occasional instance crashes. It also appears that = some application-side workloads may not be optimized for PostgreSQL.

From a DBA perspective, I=E2=80=99m looking to proactively identify prob= lem areas=E2=80=94such as:

  • Long-running queries
  • Jobs/stored procedures consuming high temp space
  • Queries resulting in sequential scans due to missing indexes
  • Lock waits, deadlocks, and memory-heavy operations

We already have key parameters enabled (pg_stat_statements,= pg_buffercache, etc.), and PostgreSQL is generating logs in <= code>.csv format. However, the main challenge is efficiently analyzi= ng these logs and identifying performance bottlenecks at scale (databases r= anging from ~1TB to 15TB).

We currently don=E2=80=99t have third-party monitoring tools like Datado= g, so I=E2=80=99m looking for recommendations on free or lightweigh= t tools and best practices to:

  • Parse and analyze PostgreSQL logs (especially CSV logs)
  • Identify top resource-consuming queries and patterns
  • Correlate temp usage, memory pressure, and query behavior
  • Generate actionable insights for the engineering team

Any suggestions on tools, scripts, or approaches that have worked well i= n similar large-scale environments would be greatly appreciated.

Have you set log_min_duration_statement to some num= ber of milliseconds?=C2=A0 When you do that, the query and its parameters s= how up in the log file.=C2=A0 Grep for "duration:" to find statem= ents taking longer than threshold=C2=A0milliseconds.

<= /div>
Does it require some manual effort?=C2=A0 Sure.=C2=A0 But it'= s free.

Barring that, try installing pgbadger.

--
Death to <Redacte= d>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
--000000000000f4f8da064f30d119--