Hosoya-san,
On 2019/03/15 15:05, Yuzuko Hosoya wrote:
> Indeed, it's problematic. I also did test and I found that
> this problem was occurred when any partition didn't match
> WHERE clauses. So following query didn't work correctly.
>
> # explain select * from test1_3 where (id > 0 and id < 30);
> QUERY PLAN
> -----------------------------------------------------------------
> Append (cost=0.00..58.16 rows=12 width=36)
> -> Seq Scan on test1_3_1 (cost=0.00..29.05 rows=6 width=36)
> Filter: ((id > 0) AND (id < 30))
> -> Seq Scan on test1_3_2 (cost=0.00..29.05 rows=6 width=36)
> Filter: ((id > 0) AND (id < 30))
> (5 rows)
>
> I created a new patch to handle this problem, and confirmed
> the query you mentioned works as expected
>
> # explain select * from test1 where (id > 0 and id < 30) or (id > 220 and id < 230);
> QUERY PLAN
> ---------------------------------------------------------------------------
> Append (cost=0.00..70.93 rows=26 width=36)
> -> Seq Scan on test1_1_1 (cost=0.00..35.40 rows=13 width=36)
> Filter: (((id > 0) AND (id < 30)) OR ((id > 220) AND (id < 230)))
> -> Seq Scan on test1_3_1 (cost=0.00..35.40 rows=13 width=36)
> Filter: (((id > 0) AND (id < 30)) OR ((id > 220) AND (id < 230)))
> (5 rows)
>
> v2 patch attached.
> Could you please check it again?
I think the updated patch breaks the promise that
get_matching_range_bounds won't set scan_default based on individual
pruning value comparisons. How about the attached delta patch that
applies on top of your earlier v1 patch, which fixes the issue reported by
Thibaut?
Thanks,
Amit