Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations
Дата
Msg-id btsjlfnqge3y6yypkwe7yvhv2tcopt6pug7gigz6xaha2iemkw@lflv3psi7xoz
обсуждение исходный текст
Ответ на Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations
Список 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 по дате отправления: