From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Alan Jackson <ajax(at)tvsquared(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: inconsistent results querying table partitioned by date |
Date: | 2019-05-16 02:52:31 |
Message-ID: | CAKJS1f8LA-z+ZyEQXimBeJhBGwFL0ic6CX5sG546=7exzc0zvQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, 16 May 2019 at 13:51, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> How about we add one more bool, say, runtime_pruning_needed to
> GeneratePruningStepsContext and set it when we discover in
> match_clause_to_partition_key() that runtime pruning will be needed? Then
> return it to make_partitionedrel_pruneinfo() using a new output parameter
> of gen_partprune_steps()?
I don't think this can be done the way you think. If we just have one
flag to say any run-time pruning is needed then we'd still need to
check op_volatile(opno) != PROVOLATILE_IMMUTABLE in
analyze_partkey_exprs() to see if an initial run-time prune is needed.
That means we might do two calls to op_volatile()! The other one is
required to set the runtime_pruning_needed in
match_clause_to_partition_key(). We can't have an additional flag to
mark what do_exec_prune should get set to either since we only know
that once we check what Param types are in the Expr and if we do that
then that's the full-blown patch that we thought might be too much
churn.
I don't really see where this duplicate call is. The patch calls
op_volatile() at the very most just once per pruning step.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-05-16 02:59:38 | Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND |
Previous Message | Michael Paquier | 2019-05-16 02:19:03 | Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND |