Re: [HACKERS] Runtime Partition Pruning

On 4 April 2018 at 18:27, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2018/04/04 11:10, David Rowley wrote:
>> On 4 April 2018 at 05:44, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> wrote:
>>> Also, I'm seeing a regression for check-world in
>>> src/test/regress/results/inherit.out
>>>
>>> ***************
>>> *** 642,648 ****
>>> ---------------------+---+---+-----
>>> mlparted_tab_part1 | 1 | a |
>>> mlparted_tab_part2a | 2 | a |
>>> ! mlparted_tab_part2b | 2 | b | xxx
>>> mlparted_tab_part3 | 3 | a | xxx
>>> (4 rows)
>>>
>>> --- 642,648 ----
>>> ---------------------+---+---+-----
>>> mlparted_tab_part1 | 1 | a |
>>> mlparted_tab_part2a | 2 | a |
>>> ! mlparted_tab_part2b | 2 | b |
>>> mlparted_tab_part3 | 3 | a | xxx
>>> (4 rows)
>>>
>>> I'll spend some more time tomorrow.
>>
>> Yeah, it's a bug in v46 faster partition pruning. Discussing a fix for
>> that with Amit over on [2].
>
> I'm not sure if we've yet discussed anything that'd be related to this on
> the faster pruning thread.

hmm, yeah, I didn't really explain the context, but the report was in [1]

Basically, the OR clause in the following SQL fragment was overwriting
the scan_all_non_null value:

where (mlp.a = ss.a and mlp.b = 'b') or mlp.a = 3;

Basically the:

result->scan_all_nonnull = step_result->scan_all_nonnull;

The minimum fix would have been to change that line to:

result->scan_all_nonnull |= step_result->scan_all_nonnull;

Anyway, it all irrelevant now as that code has all changed.

[1] https://www.postgresql.org/message-id/CAKJS1f_SHPuqDhQWJq-_P1kpPQn7BJt71yPbDP_8b3rhwFQyGA@mail.gmail.com

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services