Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit708931c

Browse files
committed
Improve ANALYZE's handling of concurrent-update scenarios.
This patch changes the rule for whether or not a tuple seen by ANALYZEshould be included in its sample.When we last touched this logic, in commit51e1445, we weren'tthinking very hard about tuples being UPDATEd by a long-runningconcurrent transaction. In such a case, we might see the pre-image aseither LIVE or DELETE_IN_PROGRESS depending on timing; and we might seethe post-image not at all, or as INSERT_IN_PROGRESS. Since the existingcode will not sample either DELETE_IN_PROGRESS or INSERT_IN_PROGRESStuples, this leads to concurrently-updated rows being omitted from thesample entirely. That's not very helpful, and it's especially the wrongthing if the concurrent transaction ends up rolling back.The right thing seems to be to sample DELETE_IN_PROGRESS rows just as ifthey were live. This makes the "sample it" and "count it" decisions thesame, which seems good for consistency. It's clearly the right thingif the concurrent transaction ends up rolling back; in effect, we aresampling as though IN_PROGRESS transactions haven't happened yet.Also, this combination of choices ensures maximum robustness againstthe different combinations of whether and in which state we might see thepre- and post-images of an update.It's slightly annoying that we end up recording immediately-out-of-datestats in the case where the transaction does commit, but on the otherhand the stats are fine for columns that didn't change in the update.And the alternative of sampling INSERT_IN_PROGRESS rows instead seemslike a bad idea, because then the sampling would be inconsistent withthe way rows are counted for the stats report.Per report from Mark Chambers; thanks to Jeff Janes for diagnosingwhat was happening. Back-patch to all supported versions.Discussion:https://postgr.es/m/CAFh58O_Myr6G3tcH3gcGrF-=OExB08PJdWZcSBcEcovaiPsrHA@mail.gmail.com
1 parent114635e commit708931c

File tree

1 file changed

+18
-3
lines changed

1 file changed

+18
-3
lines changed

‎src/backend/commands/analyze.c

Lines changed: 18 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1131,20 +1131,35 @@ acquire_sample_rows(Relation onerel, int elevel,
11311131
caseHEAPTUPLE_DELETE_IN_PROGRESS:
11321132

11331133
/*
1134-
* We count delete-in-progress rows as still live, using
1135-
* the same reasoning given above; but we don't bother to
1136-
* include them in the sample.
1134+
* We count and sample delete-in-progress rows the same as
1135+
* live ones, so that the stats counters come out right if
1136+
* the deleting transaction commits after us, per the same
1137+
* reasoning given above.
11371138
*
11381139
* If the delete was done by our own transaction, however,
11391140
* we must count the row as dead to make
11401141
* pgstat_report_analyze's stats adjustments come out
11411142
* right. (Note: this works out properly when the row was
11421143
* both inserted and deleted in our xact.)
1144+
*
1145+
* The net effect of these choices is that we act as
1146+
* though an IN_PROGRESS transaction hasn't happened yet,
1147+
* except if it is our own transaction, which we assume
1148+
* has happened.
1149+
*
1150+
* This approach ensures that we behave sanely if we see
1151+
* both the pre-image and post-image rows for a row being
1152+
* updated by a concurrent transaction: we will sample the
1153+
* pre-image but not the post-image. We also get sane
1154+
* results if the concurrent transaction never commits.
11431155
*/
11441156
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(targtuple.t_data)))
11451157
deadrows+=1;
11461158
else
1159+
{
1160+
sample_it= true;
11471161
liverows+=1;
1162+
}
11481163
break;
11491164

11501165
default:

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp