Hi David. On 2018/02/23 0:11, David Rowley wrote: > On 23 February 2018 at 01:15, David Rowley <david.row...@2ndquadrant.com> > wrote: >> One problem that I'm facing now is down to the way I'm gathering the >> ParamIds that match the partkeys. As you'll see from the patch I've >> added a 'paramids' field to PartitionPruneContext and I'm populating >> this when the clauses are being pre-processed in >> extract_partition_clauses(). The problem is that the or_clauses are >> not pre-processed at all, so the current patch will not properly >> perform run-time pruning when the Params are "hidden" in OR branches. >> >> One way I thought to fix this was to change the clause processing to >> create an array of PartitionClauseInfos, one for each OR branch. This >> would also improve the performance of the run-time pruning, meaning >> that all of the or clauses would be already matched to the partition >> keys once, rather than having to redo that again each time a Param >> changes its value. >> >> If I go and write a patch to do that, would you want it in your patch, >> or would you rather I kept it over here? Or perhaps you have a better >> idea on how to solve...? > > I've attached a patch which does this. For now, the patch is only > intended to assist in the discussion of the above idea. > > The patch is based on a WIP version of run-time pruning that I'm not > quite ready to post yet, but with a small amount of work you could > probably take it and base it on your faster partition pruning v31 > patch [1]. > > I ended up pulling the PartitionPruneInfo out of the > PartitionPruneContext. This was required due how I've now made > extract_partition_clauses() recursively call itself. We don't want to > overwrite the context's clauseinfo with the one from the recursive > call. A side effect of this is that the subcontext is no longer > required when processing the OR clauses. You only did this so that the > context's clauseinfo was not overwritten. I also think it's better to > seperate out the inputs and outputs. Anything in context was more > intended to be for input fields. > > Let me know your thoughts about this. If you don't want it for faster > partition pruning, then I'll probably go and tidy it up and include it > for run-time pruning.
Thanks for the patch. I don't have time today to look at the patch closely, but at first blush, it seems like something I should incorporate into my own patch, because it's restructuring the partprune.c code. I will study the issue and your proposed solution in the form of this restructuring more closely over the weekend and reply (probably with a new version of my patch) on Monday. Thanks, Amit
