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-15 02:47:47 |
Message-ID: | CAKJS1f-ABcw68AH7tRRRmBTEwhd-Y_Lm8HpfydWw6aPS8G715A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, 15 May 2019 at 14:20, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> Additionally, I'm wondering if we should also apply the attached as
> part of my dont_prune_with_nonimmutable_opfuncs_during_planning_v2.patch
> patch. We should never get a non-Const in the pruning steps for
> planning, so there's likely no point in doing a run-time check to
> ensure we have a planstate. This code can execute quite often during
> run-time pruning, once each time a parameter changes, which could be
> each row. I think I'll go do that now, and also fix up that
> forplanner comment you mentioned.
I've made the change to partkey_datum_from_expr() in master's version
only. I did this because I had to document that the context argument
in get_matching_partitions() must have a valid planstate set when the
given pruning_steps were generated for the executor. It's probably
unlikely that anything else is using these functions, but still
thought it was a bad idea to change that in v11. At this stage, I
don't see any big issues changing that in master.
The only change in
pg11_dont_prune_with_nonimmutable_opfuncs_during_planning_v3.patch
since v2 is the inaccurate comment mentioned by Amit.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
pg11_dont_prune_with_nonimmutable_opfuncs_during_planning_v3.patch | application/octet-stream | 9.8 KB |
dont_prune_with_nonimmutable_opfuncs_during_planning_v3.patch | application/octet-stream | 11.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-05-15 07:31:25 | Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND |
Previous Message | David Rowley | 2019-05-15 02:20:14 | Re: inconsistent results querying table partitioned by date |