On 2017-07-29 14:20:32 -0400, Tom Lane wrote: > Here's a reviewed version of this patch.
Thanks! > * I think you put ExecScan's CFI in the wrong place; AFAICT yours > only covers its fast path. Sure - but the old path already has a CFI? And it has to be inside the loop, because well, the loop ;). > * I think ExecAgg needs a CFI at the head, just to be sure it's hit > in any path through that. Yep, makes esense. > * I agree that putting CFI inside ExecHashJoin's state machine loop > is a good idea, because it might have to trawl through quite a lot of > a batch file before finding a returnable tuple. But I think in merge > and nestloop joins it's sufficient to put one CFI at the head. Neither > of those cases can do very much processing without invoking a child > node, where a CFI will happen. Ok, I can live with that. > * You missed ExecLockRows altogether. Well, it directly calls the next ExecProcNode(), so I didn't think it was necessary. One of the aforementioned judgement calls. But I'm perfectly happy to have one there. Thanks, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
