On Tue, 14 May 2019 at 16:07, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> The problem is different. '2018-01-01'::timestamptz' in the condition
> datadatetime < '2018-01-01'::timestamptz as presented to
> match_clause_to_partition_key() is indeed a Const node, making it think
> that it's OK to prune using it, that is, with or without your patch.
Looks like I misunderstood the problem.
Is it not still better to ignore the unsupported quals in
match_clause_to_partition_key() rather than crafting a new List of
just the valid ones like you've done in your patch?
I admit that at some point during our parallel development of pruning
and run-time pruning, I thought that the pruning steps generated for
plan-time pruning could have been reused for run-time pruning, but we
can't do that since we must also use parameterised quals, which are
not in the baserestrictinfo therefore not there when we generate the
steps for the plan-time pruning. I feel that what you've got spreads
the logic out a bit too much. match_clause_to_partition_key() has
traditionally been in charge of deciding what quals can be used and
which ones can't. You've gone and added logic in
prune_append_rel_partitions() that makes part of this decision now and
that feels a bit wrong to me.
I've attached patch of how I think it should work. This includes the
changes you made to analyze_partkey_exprs() and your tests from
v1-0003-Fix-planner-to-not-prune-partitions-with-non-immu.patch
Do you think it's a bad idea to do it this way?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services