• Andres Freund's avatar
    Reorder EPQ work, to fix rowmark related bugs and improve efficiency. · 27cc7cd2
    Andres Freund authored
    In ad0bda5d I changed the EvalPlanQual machinery to store
    substitution tuples in slot, instead of using plain HeapTuples. The
    main motivation for that was that using HeapTuples will be inefficient
    for future tableams.  But it turns out that that conversion was buggy
    for non-locking rowmarks - the wrong tuple descriptor was used to
    create the slot.
    
    As a secondary issue 5db6df0c changed ExecLockRows() to begin EPQ
    earlier, to allow to fetch the locked rows directly into the EPQ
    slots, instead of having to copy tuples around. Unfortunately, as Tom
    complained, that forces some expensive initialization to happen
    earlier.
    
    As a third issue, the test coverage for EPQ was clearly insufficient.
    
    Fixing the first issue is unfortunately not trivial: Non-locked row
    marks were fetched at the start of EPQ, and we don't have the type
    information for the rowmarks available at that point. While we could
    change that, it's not easy. It might be worthwhile to change that at
    some point, but to fix this bug, it seems better to delay fetching
    non-locking rowmarks when they're actually needed, rather than
    eagerly. They're referenced at most once, and in cases where EPQ
    fails, might never be referenced. Fetching them when needed also
    increases locality a bit.
    
    To be able to fetch rowmarks during execution, rather than
    initialization, we need to be able to access the active EPQState, as
    that contains necessary data. To do so move EPQ related data from
    EState 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 of
    EvalPlanQualSlot() to be used before EvalPlanQualBegin() (but
    obviously still requiring EvalPlanQualInit() to have been done).
    
    As these changes made struct EState harder to understand, e.g. by
    adding multiple EStates, significantly reorder the members, and add a
    lot more comments.
    
    Also add a few more EPQ tests, including one that fails for the first
    issue above. More is needed.
    
    Reported-By: yi huang
    Author: Andres Freund
    Reviewed-By: Tom Lane
    Discussion:
        https://postgr.es/m/CAHU7rYZo_C4ULsAx_LAj8az9zqgrD8WDd4hTegDTMM1LMqrBsg@mail.gmail.com
        https://postgr.es/m/24530.1562686693@sss.pgh.pa.us
    Backpatch: 12-, where the EPQ changes were introduced
    27cc7cd2
trigger.c 187 KB