Re: [HACKERS] path toward faster partition pruning

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: [HACKERS] path toward faster partition pruning
Дата
Msg-id bd98dca1-340f-43ea-fcb4-099aa563594d@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (Beena Emerson <memissemerson@gmail.com>)
Ответы Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
Thanks a lot Rajkumar and Beena for the tests.

On 2017/10/24 1:38, Beena Emerson wrote:
> On Mon, Oct 23, 2017 at 3:24 PM, Rajkumar Raghuwanshi wrote:
>> Thanks for updated patches, I am able to compile it on head.
>>
>> While testing this, I got an observation, pruning is not scanning default
>> partition leading to wrong output. below is test to reproduce this.
>>
>> create table rp (a int, b varchar) partition by range (a);
>> create table rp_p1 partition of rp default;
>> create table rp_p2 partition of rp for values from (1) to (10);
>> create table rp_p3 partition of rp for values from (10) to (maxvalue);
>>
>> insert into rp values (-1,'p1');
>> insert into rp values (1,'p2');
>> insert into rp values (11,'p3');
>>
>> postgres=# select tableoid::regclass,* from rp;
>>  tableoid | a  | b
>> ----------+----+----
>>  rp_p2    |  1 | p2
>>  rp_p3    | 11 | p3
>>  rp_p1    | -1 | p1
>> (3 rows)
>>
>> --with pruning
>> postgres=# explain (costs off) select * from rp where a <= 1;
>>         QUERY PLAN
>> --------------------------
>>  Append
>>    ->  Seq Scan on rp_p2
>>          Filter: (a <= 1)
>> (3 rows)
>>
>> postgres=# select * from rp where a <= 1;
>>  a | b
>> ---+----
>>  1 | p2
>> (1 row)

Both this (wrong output)...

> I had noticed this and also that this crash:
> 
> tprt PARTITION BY RANGE(Col1)
>        tprt_1 FOR VALUES FROM (1) TO (50001) PARTITION BY RANGE(Col1)
>               tprt_11 FOR VALUES FROM (1) TO (10000),
>               tprt_1d DEFAULT
>        tprt_2 FOR VALUES FROM (50001) TO (100001)
> 
> EXPLAIN (COSTS OFF) SELECT * FROM tprt WHERE col1 BETWEEN 20000 AND 70000;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !>

...and this (crash) were due to bugs in the 0005 patch.

Output with the updated patch for Rajkumar's test:

explain (costs off ) select * from rp where a <= 1;
        QUERY PLAN
--------------------------
 Append
   ->  Seq Scan on rp_p2
         Filter: (a <= 1)
   ->  Seq Scan on rp_p1
         Filter: (a <= 1)
(5 rows)

select tableoid::regclass, * from rp where a <= 1;
 tableoid | a  | b
----------+----+----
 rp_p2    |  1 | p2
 rp_p1    | -1 | p1
(2 rows)

-- moreover
select tableoid::regclass, * from rp where a < 1;
 tableoid | a  | b
----------+----+----
 rp_d     | -1 | p1
(1 row)


Should be fixed in the attached updated version.  While fixing the bugs, I
made some significant revisions to the code introduced by 0005.

No significant changes to any of the patches 0001-0004.

Thanks,
Amit

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Khandekar
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning