Hi, On 2017-07-18 21:49:27 +0900, Yugo Nagata wrote: > After a DML is perfomed, the statistics is sent to pgstat by > pgsent_report_sent(). > However, the mininum time between stas file update is PGSTAT_STAT_INTERVAL, > so if > a few DMLs are performed with short interval, some statistics could not be > sent > until the backend is shutdown. > > This is not a problem in usual cases, but in case that a session is remained > in > idle for a long time, for example when using connection pooling, statistics of > a huge change of a table is not sent for a long time, and as a result, > starting > autovacuum might be delayed.
Hm. > An idea to resolve this is call pgsent_report_sent() again with a delay > after the last DML to make sure to send the statistics. The attached patch > implements this. That seems like it'd add a good number of new wakeups, or at least scheduling of wakeups. Now a timer would be armed whenever a query is run outside of a transaction - something happening quite regularly. And it'd do so even if a) there are no outstanding stat reports b) there's already a timer running. Additionally it'd, unless I mis-skimmed, trigger pgstat_report_stat() from within CHECK_FOR_INTERRUPTS/ProcessInterrupts even when inside a transaction, if that transaction is started after the enable_timeout_after(). I'm not entirely sure what a good solution would be. One option would be to have a regular wakeup setting a flag (considerably longer than 500ms, that's way too many additional wakeups), rearm the timer in the handler, but only process the flag when outside of a transaction. Or we could do nothing - I actually think that's a viable option. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
