Re: inconsistent results querying table partitioned by date

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, 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-17 13:53:11
Message-ID: 7235.1558101191@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> As promised, here is the idea I was thinking of, although I'm no longer
> confident you will like it based on your previous emails on this thread.
> I was thinking of having a walker function that traverses the list of
> *clauses* that were passed to make_partition_pruneinfo(), which puts the
> paramids into an output context struct, with separate Bitmapsets for
> PARAM_EXTERN and PARAM_EXEC parameters. In addition to running this
> walker, also do a contain_mutable_functions() pass over the clauses. (I
> can already hear a big no at this point!) As you might've guessed, the
> result of those two steps would decide whether we need to do the the extra
> gen_partprune_steps() steps. Fwiw, I prototyped it in the attached patch
> which applies on top of yours.

Actually, yeah, my thoughts about future development were to split up
the gen_partprune_steps processing to avoid the duplicated work.
I've not read your patch yet but this sounds like the same idea.
What I'm worried about is if it's too much code churn for a
back-patchable bug fix.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-05-17 15:46:17 BUG #15812: Select statement of a very big number, with a division operator seems to round up.
Previous Message Amit Langote 2019-05-17 10:49:19 Re: inconsistent results querying table partitioned by date