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 по дате отправления: