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 13:42:31
Message-ID: 18454.1500385351@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> That seems like it'd add a good number of new wakeups, or at least
> scheduling of wakeups.

Yes, as it stands this will result in a huge increase in alarm-scheduling
kernel call traffic. I understand the issue but I do not think this is
an acceptable path to a fix.

> Or we could do nothing - I actually think that's a viable option.

I tend to agree. I'm not really sure that the presented problem is a
big deal: for it to be an issue, you have to assume that a DML operation
that takes less than PGSTAT_STAT_INTERVAL is capable of causing enough
table churn that it's a problem if autovacuum doesn't hear about that
churn promptly.

I wonder if a better answer wouldn't be to reduce PGSTAT_STAT_INTERVAL.
I don't think that value has been reconsidered since the code was written,
circa turn of the century. Maybe even make it configurable, though that
could be overkill.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-07-18 13:50:01 Re: [PATCH] Make sure all statistics is sent after a few DML are performed
Previous Message Marina Polyakova 2017-07-18 13:16:19 Re: WIP Patch: Precalculate stable functions, infrastructure v1