On 4 April 2018 at 18:27, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2018/04/04 11:10, David Rowley wrote: >> On 4 April 2018 at 05:44, Jesper Pedersen <jesper.peder...@redhat.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_8b3rhwfq...@mail.gmail.com -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
