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

Commitfc8addd

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 parent1b0294d commitfc8addd

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
@@ -1165,20 +1165,35 @@ acquire_sample_rows(Relation onerel, int elevel,
11651165
caseHEAPTUPLE_DELETE_IN_PROGRESS:
11661166

11671167
/*
1168-
* We count delete-in-progress rows as still live, using
1169-
* the same reasoning given above; but we don't bother to
1170-
* include them in the sample.
1168+
* We count and sample delete-in-progress rows the same as
1169+
* live ones, so that the stats counters come out right if
1170+
* the deleting transaction commits after us, per the same
1171+
* reasoning given above.
11711172
*
11721173
* If the delete was done by our own transaction, however,
11731174
* we must count the row as dead to make
11741175
* pgstat_report_analyze's stats adjustments come out
11751176
* right. (Note: this works out properly when the row was
11761177
* both inserted and deleted in our xact.)
1178+
*
1179+
* The net effect of these choices is that we act as
1180+
* though an IN_PROGRESS transaction hasn't happened yet,
1181+
* except if it is our own transaction, which we assume
1182+
* has happened.
1183+
*
1184+
* This approach ensures that we behave sanely if we see
1185+
* both the pre-image and post-image rows for a row being
1186+
* updated by a concurrent transaction: we will sample the
1187+
* pre-image but not the post-image. We also get sane
1188+
* results if the concurrent transaction never commits.
11771189
*/
11781190
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(targtuple.t_data)))
11791191
deadrows+=1;
11801192
else
1193+
{
1194+
sample_it= true;
11811195
liverows+=1;
1196+
}
11821197
break;
11831198

11841199
default:

0 commit comments

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