Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations
Date
Msg-id btsjlfnqge3y6yypkwe7yvhv2tcopt6pug7gigz6xaha2iemkw@lflv3psi7xoz
Whole thread Raw
In response to Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations
List pgsql-hackers
Hi,

On 2025-08-19 09:20:23 +0900, Michael Paquier wrote:
> On Mon, Aug 18, 2025 at 03:10:42PM -0500, Sami Imseih wrote:
> > I agree, but I think it's time to start thinking about splitting
> > pg_stat_statements into multiple functions. This was recently
> > discussed [0]
> 
> Yes, no idea for other people, but I'm putting a stop to new additions
> until we've split the SQL facing interface a bit, removing some bloat
> from the main pgss view.  So says the guy who has just bumped pgss to
> 1.13 a couple of weeks ago, so it sounds a bit metaphoric.

I think the problem isn't mainly the SQL view, it's that all the additions
made pg_stat_statements have so much overhead that it's practically unusable
for any busy workload. It used to be only an issue on really big servers, but
there's been so much crap stuffed into pgss that it's trivially reproducible
on a laptop.

I think it's pretty insane to do things like variance computation while
holding a spinlock, for every friggin query execution. The spinlock'ed section
is ~185 instructions for me, with plenty high-latency instructions like
divisions.

It's so slow that it has measurable impact for single threaded readonly
pgbench. Which does friggin btree lookups.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: New commitfest app release on August 19th
Next
From: Florents Tselai
Date:
Subject: Re: mention unused_oids script in pg_proc.dat