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

Commit27cc7cd

Browse files
committed
Reorder EPQ work, to fix rowmark related bugs and improve efficiency.
Inad0bda5 I changed the EvalPlanQual machinery to storesubstitution tuples in slot, instead of using plain HeapTuples. Themain motivation for that was that using HeapTuples will be inefficientfor future tableams. But it turns out that that conversion was buggyfor non-locking rowmarks - the wrong tuple descriptor was used tocreate the slot.As a secondary issue5db6df0 changed ExecLockRows() to begin EPQearlier, to allow to fetch the locked rows directly into the EPQslots, instead of having to copy tuples around. Unfortunately, as Tomcomplained, that forces some expensive initialization to happenearlier.As a third issue, the test coverage for EPQ was clearly insufficient.Fixing the first issue is unfortunately not trivial: Non-locked rowmarks were fetched at the start of EPQ, and we don't have the typeinformation for the rowmarks available at that point. While we couldchange that, it's not easy. It might be worthwhile to change that atsome point, but to fix this bug, it seems better to delay fetchingnon-locking rowmarks when they're actually needed, rather thaneagerly. They're referenced at most once, and in cases where EPQfails, might never be referenced. Fetching them when needed alsoincreases locality a bit.To be able to fetch rowmarks during execution, rather thaninitialization, we need to be able to access the active EPQState, asthat contains necessary data. To do so move EPQ related data fromEState to EPQState, and, only for EStates creates as part of EPQ,reference the associated EPQState from EState.To fix the second issue, change EPQ initialization to allow use ofEvalPlanQualSlot() to be used before EvalPlanQualBegin() (butobviously still requiring EvalPlanQualInit() to have been done).As these changes made struct EState harder to understand, e.g. byadding multiple EStates, significantly reorder the members, and add alot more comments.Also add a few more EPQ tests, including one that fails for the firstissue above. More is needed.Reported-By: yi huangAuthor: Andres FreundReviewed-By: Tom LaneDiscussion:https://postgr.es/m/CAHU7rYZo_C4ULsAx_LAj8az9zqgrD8WDd4hTegDTMM1LMqrBsg@mail.gmail.comhttps://postgr.es/m/24530.1562686693@sss.pgh.pa.usBackpatch: 12-, where the EPQ changes were introduced
1 parent7e04160 commit27cc7cd

File tree

12 files changed

+705
-273
lines changed

12 files changed

+705
-273
lines changed

‎src/backend/commands/trigger.c

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3363,8 +3363,7 @@ GetTupleForTrigger(EState *estate,
33633363
{
33643364
TupleTableSlot*epqslot;
33653365

3366-
epqslot=EvalPlanQual(estate,
3367-
epqstate,
3366+
epqslot=EvalPlanQual(epqstate,
33683367
relation,
33693368
relinfo->ri_RangeTableIndex,
33703369
oldslot);

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp