Re: Per backend relation statistics tracking
От
Bertrand Drouvot
Тема
Re: Per backend relation statistics tracking
Дата
Msg-id
aK2B6Fn86NFWP73k@ip-10-97-1-34.eu-west-3.compute.internal
Ответ на
Re: Per backend relation statistics tracking (Bertrand Drouvot)
Список
Дерево обсуждения
Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Andres Freund <andres@anarazel.de>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Andres Freund <andres@anarazel.de>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Sami Imseih <samimseih@gmail.com>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Sami Imseih <samimseih@gmail.com>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Michael Paquier <michael@paquier.xyz>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Per backend relation statistics tracking Sami Imseih <samimseih@gmail.com>
Re: Per backend relation statistics tracking Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Hi, On Tue, Aug 26, 2025 at 06:38:41AM +0000, Bertrand Drouvot wrote: > Hi, > > On Mon, Aug 25, 2025 at 08:28:04PM -0400, Andres Freund wrote: > > I don't like that this basically doubles the overhead of keeping stats by > > tracking everythign twice. The proper solution is to do that not in the hot > > path (i.e. in scans), but when summarizing stats to be flushed to the shared > > stats. > > I do agree, like when the relations stats are flushed then we do update the > database ones too. I'll use the same approach in the next revision. Something along the lines like in the attached (I'm just providing 0001 here, will do the others if we agree on the proposal)? Remark: We could avoid the new branch in pgstat_relation_flush_cb() if we split tables and indexes stats, but I don't think that should be a blocker for per backend relations stats. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления
От: Andrey Borodin
Дата: