On 2019/05/15 5:58, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> On 2019/05/14 15:09, David Rowley wrote:
>>> Do you think it's a bad idea to do it this way?
>
>> As I mentioned above, I think this may be quite a bit of code churn for
>> enforcing a policy that's elsewhere enforced in a much simpler manner.
>> How about deferring this to committer?
>
> Not sure I'll be the one to commit this, but ...
Thanks for the feedback.
> I don't much like the approach in
> v1-0003-Fix-planner-to-not-prune-partitions-with-non-immu.patch
> because (a) it appears to me to add duplicative expression mutability
> testing, which is kind of expensive since that adds syscache lookups,
> plus it adds such tests even for clauses that aren't going to match any
> partition keys; and (b) it's extremely nonobvious that this restricts
> plan-time pruning and not run-time pruning. I do see that
> prune_append_rel_partitions is used only for the former; but you sure
> as heck can't deduce that from any of its comments, so somebody might
> try to use it for run-time pruning.
OK, both a and b are good arguments.
> So I think David's got the right idea that match_clause_to_partition_key
> is where to handle this, and I like the fact that his patch explicitly
> represents whether we're trying to do run-time or plan-time pruning.
Agreed that David's latest patch is good for this.
> Also, I'm a bit confused by the fact that we seem to have a bunch
> of spare-parts patches in this thread. What combination is actually
> being proposed for commit?
Sorry for the confusion.
0001 adds tests for the other bugs but with the wrong expected output
0002 fixes those bugs and shows the corrected output
0003 was for the bug that stable operators are being used for plan-time
pruning which has its own test (only 0003 needed separate versions for
HEAD and v11)
Parts of 0003 are now superseded by David's patch, of which he has posted
both for-HEAD and for-v11 versions.
0001+0002 is obviously meant to be squashed, which I'll do in a bit.
Thanks,
Amit