Andres Freund <> 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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to