Re: BUG #16500: SQL Abend. select multi_key_columns_range_partition_table
От | Etsuro Fujita |
---|---|
Тема | Re: BUG #16500: SQL Abend. select multi_key_columns_range_partition_table |
Дата | |
Msg-id | CAPmGK14hoZJhBBSQoRKMUAxsp=uy0=gLGUg1BtejkF=k-dh8fg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16500: SQL Abend. select multi_key_columns_range_partition_table (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: BUG #16500: SQL Abend. select multi_key_columns_range_partition_table
|
Список | pgsql-bugs |
On Thu, Jul 2, 2020 at 8:52 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > I'll look at the patch more closely tomorrow. I spent some time reviewing the patch, and noticed that the changes to gen_prune_steps_from_opexps() break the logic in get_matching_range_bounds(), causing another issue. Here is an example: postgres=# create table prefix_test (a int, b varchar) partition by range (a, b); postgres=# create table prefix_test1 partition of prefix_test for values from (1, 'a') to (1, 'b'); postgres=# create table prefix_test2 partition of prefix_test for values from (2, 'a') to (2, 'b'); postgres=# set enable_partition_pruning to on; postgres=# explain select * from prefix_test where a <= 2 and b = 'a'; QUERY PLAN -------------------------------------------------------------------------- Seq Scan on prefix_test2 prefix_test (cost=0.00..29.05 rows=2 width=36) Filter: ((a <= 2) AND ((b)::text = 'a'::text)) (2 rows) Will do a bit more investigation about this. Best regards, Etsuro Fujita
В списке pgsql-bugs по дате отправления: