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

Commit60de80c

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 parentba26b31 commit60de80c

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
@@ -1110,20 +1110,35 @@ acquire_sample_rows(Relation onerel, int elevel,
11101110
caseHEAPTUPLE_DELETE_IN_PROGRESS:
11111111

11121112
/*
1113-
* We count delete-in-progress rows as still live, using
1114-
* the same reasoning given above; but we don't bother to
1115-
* include them in the sample.
1113+
* We count and sample delete-in-progress rows the same as
1114+
* live ones, so that the stats counters come out right if
1115+
* the deleting transaction commits after us, per the same
1116+
* reasoning given above.
11161117
*
11171118
* If the delete was done by our own transaction, however,
11181119
* we must count the row as dead to make
11191120
* pgstat_report_analyze's stats adjustments come out
11201121
* right. (Note: this works out properly when the row was
11211122
* both inserted and deleted in our xact.)
1123+
*
1124+
* The net effect of these choices is that we act as
1125+
* though an IN_PROGRESS transaction hasn't happened yet,
1126+
* except if it is our own transaction, which we assume
1127+
* has happened.
1128+
*
1129+
* This approach ensures that we behave sanely if we see
1130+
* both the pre-image and post-image rows for a row being
1131+
* updated by a concurrent transaction: we will sample the
1132+
* pre-image but not the post-image. We also get sane
1133+
* results if the concurrent transaction never commits.
11221134
*/
11231135
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(targtuple.t_data)))
11241136
deadrows+=1;
11251137
else
1138+
{
1139+
sample_it= true;
11261140
liverows+=1;
1141+
}
11271142
break;
11281143

11291144
default:

0 commit comments

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