On Tue, Aug 13, 2019 at 9:28 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Tue, Aug 13, 2019 at 3:18 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> To clarify my position --- I think it's definitely possible to improve > >> the situation a great deal. We "just" have to pass down more information > >> about whether rescans are possible. > > > Right, you have speculated above that it is possible via adding some > > eflag bits. Can you please describe a bit more about that idea, so > > that somebody else can try to write a patch? > > Well, there are two components to solving this problem: > > 1. What are we going to do about the executor's external API? > > Right now, callers of ExecutorStart don't have to say whether they > might call ExecutorRewind. We need some way for callers to make a > binding promise that they won't do any such thing. Perhaps we just > want to invent another flag that's like EXEC_FLAG_BACKWARD, but it's > not clear how it should interact with the existing "soft" REWIND > flag.
Yeah making it interact with REWIND will be a bit of challenge as I think to some extent the REWIND flag also indicates the same. Do I understand correctly that, we have some form of rule such that if EXEC_FLAG_REWIND is set or node's chgParam is NULL, then we can expect that node can support rescan? If it is true, then maybe we need to design this new flag in such a way that it covers existing cases of REWIND as well. Another point which I am wondering is why can't we use the existing REWIND flag to solve the current issue, basically if we have access to that information in nodeLimit.c (ExecLimit), then can't we just pass down that to ExecShutdownNode? I guess the problem could be that if LimitNode doesn't support REWIND, but one of the nodes beneath it supports that same, then we won't be able to rely on the information passed to ExecShutdownNode. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
