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 по дате отправления: