From: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Make sure all statistics is sent after a few DML are performed |
Date: | 2017-07-19 05:04:39 |
Message-ID: | 20170719140439.64ac0c48.nagata@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 18 Jul 2017 10:10:49 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
Thank you for your comments. I understand the problem of my proposal
patch.
> 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
--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-07-19 05:39:22 | Re: merge psql ef/ev sf/sv handling functions |
Previous Message | Rafia Sabih | 2017-07-19 04:24:12 | Re: Partition-wise join for join between (declaratively) partitioned tables |