RE: speeding up planning with partitions

Поиск
Список
Период
Сортировка
От Imai, Yoshikazu
Тема RE: speeding up planning with partitions
Дата
Msg-id 0F97FA9ABBDBE54F91744A9B37151A5129E34B@g01jpexmbkw24
обсуждение исходный текст
Ответ на RE: speeding up planning with partitions  ("Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>)
Ответы Re: speeding up planning with partitions
Список pgsql-hackers
Amit-san,

I have done code review of v31 patches from 0004 to 0008.

0004:
* s/childern/children

0005:
* This seems reasonable for not using a lot of memory in specific case, although it needs special looking of planner
experts.

0006:
* The codes initializing/setting RelOptInfo's part_rels looks like a bit complicated, but I didn't come up with any
gooddesign so far.
 

0007:
* This changes some processes using "for loop" to using "while(bms_next_member())" which speeds up processing when we
scanfew partitions in one statement, but when we scan a lot of partitions in one statement, its performance will likely
degraded.I measured the performance of both cases.
 
I executed select statement to the table which has 4096 partitions.

[scanning 1 partition]
Without 0007 : 3,450 TPS
With 0007    : 3,723 TPS

[scanning 4096 partitions]
Without 0007 : 10.8 TPS
With 0007    : 10.5 TPS

In the above result, performance degrades 3% in case of scanning 4096 partitions compared before and after applying
0007patch. I think when scanning a lot of tables, executor time would be also longer, so the increasement of planner
timewould be relatively smaller than it. So we might not have to care this performance degradation.
 

0008:
This seems ok.


--
Yoshikazu Imai


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

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: pgsql: Add support for hyperbolic functions, as well as log10().
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Sparse bit set data structure