RE: speeding up planning with partitions - Mailing list pgsql-hackers

From Imai, Yoshikazu
Subject RE: speeding up planning with partitions
Date
Msg-id 0F97FA9ABBDBE54F91744A9B37151A5129E34B@g01jpexmbkw24
Whole thread Raw
In response to RE: speeding up planning with partitions  ("Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>)
Responses Re: speeding up planning with partitions
List 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 by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: pgsql: Add support for hyperbolic functions, as well as log10().
Next
From: Heikki Linnakangas
Date:
Subject: Re: Sparse bit set data structure