Re: [PATCH] Make sure all statistics is sent after a few DML are performed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Make sure all statistics is sent after a few DML are performed
Date: 2017-07-18 14:10:49
Message-ID: 21239.1500387049@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shubham Barai 2017-07-18 14:36:01 GSoC 2017: weekly progress reports (week 7)
Previous Message David Fetter 2017-07-18 13:55:36 Re: Patch: Add --no-comments to skip COMMENTs with pg_dump