Re: inconsistent results querying table partitioned by date

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

In response to

Responses

Browse pgsql-bugs by date

  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