| 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: | Whole Thread | Raw Message | Download mbox | Resend email |
| 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
| 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 |