database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-26 23:43:30 +03:00
Code Activity

Don't reset changes_since_analyze after a selective-columns ANALYZE.

Browse Source 
If we ANALYZE only selected columns of a table, we should not postpone
auto-analyze because of that; other columns may well still need stats
updates.  As committed, the counter is left alone if a column list is
given, whether or not it includes all analyzable columns of the table.
Per complaint from Tomasz Ostrowski.

It's been like this a long time, so back-patch to all supported branches.

Report: <ef99c1bd-ff60-5f32-2733-c7b504eb960c@ato.waw.pl>
This commit is contained in:
Tom Lane
2016-06-06 17:44:17 -04:00
parent c6dbf1fe79
commit f64340e743
3 changed files with 19 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/backend/postmaster/pgstat.c
View File

@@ -1340,11 +1340,15 @@ pgstat_report_vacuum(Oid tableoid, bool shared,
* pgstat_report_analyze() -
*
* Tell the collector about the table we just analyzed.
*
* Caller must provide new live- and dead-tuples estimates, as well as a
* flag indicating whether to reset the changes_since_analyze counter.
* --------
*/
void
pgstat_report_analyze(Relation rel,
PgStat_Counter livetuples, PgStat_Counter deadtuples)
PgStat_Counter livetuples, PgStat_Counter deadtuples,
bool resetcounter)
{
PgStat_MsgAnalyze msg;
@@ -1381,6 +1385,7 @@ pgstat_report_analyze(Relation rel,
msg.m_databaseid = rel->rd_rel->relisshared ? InvalidOid : MyDatabaseId;
msg.m_tableoid = RelationGetRelid(rel);
msg.m_autovacuum = IsAutoVacuumWorkerProcess();
msg.m_resetcounter = resetcounter;
msg.m_analyzetime = GetCurrentTimestamp();
msg.m_live_tuples = livetuples;
msg.m_dead_tuples = deadtuples;
@@ -5263,10 +5268,12 @@ pgstat_recv_analyze(PgStat_MsgAnalyze *msg, int len)
tabentry->n_dead_tuples = msg->m_dead_tuples;
/*
* We reset changes_since_analyze to zero, forgetting any changes that
* occurred while the ANALYZE was in progress.
* If commanded, reset changes_since_analyze to zero. This forgets any
* changes that were committed while the ANALYZE was in progress, but we
* have no good way to estimate how many of those there were.
*/
tabentry->changes_since_analyze = 0;
if (msg->m_resetcounter)
tabentry->changes_since_analyze = 0;
if (msg->m_autovacuum)
{