Re: [HACKERS] [PATCH] Make sure all statistics is sent after a fewDML are performed
От | Yugo Nagata |
---|---|
Тема | Re: [HACKERS] [PATCH] Make sure all statistics is sent after a fewDML are performed |
Дата | |
Msg-id | 20170719140439.64ac0c48.nagata@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Make sure all statistics is sent after a few DML are performed (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [PATCH] Make sure all statistics is sent after a fewDML are performed
|
Список | pgsql-hackers |
On Tue, 18 Jul 2017 10:10:49 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: Thank you for your comments. I understand the problem of my proposal patch. > Andres Freund <andres@anarazel.de> writes: > > On 2017-07-18 09:42:31 -0400, Tom Lane wrote: > >> I wonder if a better answer wouldn't be to reduce PGSTAT_STAT_INTERVAL. > > > Not sure if that really does that much to solve the concern. > > Well, it reduces the amount of data churn that a statement shorter than > PGSTAT_STAT_INTERVAL could cause. > > > Another, > > pretty half-baked, approach would be to add a procsignal triggering idle > > backends to send stats, and send that to all idle backends when querying > > stats. We could even publish the number of outstanding stats updates in > > PGXACT or such, without any locking, and send it only to those that have > > outstanding ones. > > If somebody wanted to do the work, that'd be a viable answer IMO. You'd > really want to not wake backends that have nothing more to send, but > I agree that it'd be possible to advertise that in shared memory. > > regards, tom lane -- Yugo Nagata <nagata@sraoss.co.jp>
В списке pgsql-hackers по дате отправления: