Stephan Szabo <[EMAIL PROTECTED]> writes:
> The advantage that I see is that we get more control over the time
> qualifications used for tuples which may come into play for match
> partial. I'm not sure that it's worth the effort to try doing it
> this way, but I figured I'd try it.
It might be better to address that directly, eg:
- define another SnapShot value that has the semantics you want
- add a field to Scan plan nodes to specify explicitly the snapshot
you want used. Presumably by default the planner would fill this
with the standard QuerySnapshot, but you could
- find a way to override the default (if nothing else, walk the
completed plan tree and tweak the snapshot settings).
I believe it's already true that scan plan nodes lock down the target
snapshot during plan node startup, by copying QuerySnapshot into node
local execution state. So maybe you don't even need the above hack;
perhaps just twiddling QuerySnapshot right before ExecutorStart would
get the job done.
It might be useful to discuss exactly what is bad or broken about the
current RI implementation, so we can get a clearer idea of what ought
to be done. I know that y'all are dissatisfied with it but I'm not
sure I fully understand the issues.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
