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...?
Hi Amit, 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 . 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.  https://www.postgresql.org/message-id/00ae2273-bb6b-1287-9ebc-5459b37c9078%40lab.ntt.co.jp -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Description: Binary data