From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, 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-14 23:52:11 |
Message-ID: | CAKJS1f82n-WNsu6G5WNXGFV4MsnosydiouRvTNnZYmQz0tciuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, 15 May 2019 at 08:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
> I agree it's kind of invasive, and I wonder why. Shouldn't the
> additional flag just be a field in the "context" struct, instead of
> being a separate parameter that has to be laboriously passed through
> many call levels?
Thanks for having a look. I originally stayed clear of "context"
since it looks more like how we output the pruning steps, rather than
a context as to how they should be generated. But it's true, using it
saves having to pass the extra argument around, so I made that change.
> (For myself, I'd have made it just a bool not an enum, given that
> I don't foresee a need for additional values. But that's definitely
> a matter of preference.)
I've changed to bool, mostly because it makes the patch a bit smaller.
> 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?
I was also confused at the extra two patches Amit posted. The extra
one for the tests didn't look very valid to me, as I mentioned
yesterday.
I propose the attached for master, and I'll post something for v11 shortly.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
dont_prune_with_nonimmutable_opfuncs_during_planning_v2.patch | application/octet-stream | 10.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-05-15 00:08:46 | Re: inconsistent results querying table partitioned by date |
Previous Message | Tom Lane | 2019-05-14 21:30:57 | Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND |