On Sat, Mar 26, 2016 at 3:18 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:

> search the last, say, two pages of the FSM in all cases.  But that
>> might be expensive. The extra call to RelationGetNumberOfBlocks seems
>> cheap enough here because the alternative is to wait for a contended
>> heavyweight lock.
> I will try the test with this also and post the results.

I have changed v14 as per this suggestion and results are same as v14.

I have again measured the relation size, this time directly using size
function so results are better understandable.

Relation Size
INSERT : 16000 transaction from 32 Client

                     Base          v13         v14_1
                    ---------      ---------      --------
TPS              37              255         112
Rel Size       17GB         17GB     18GB

COPY: 32000 transaction from 32 client
                     Base          v13        v14_1
                   ---------        ---------    ---------
TPS              121           823         427
Rel Size       11GB        11GB       11GB

Script are attached in the mail
test_size_ins.sh  --> run insert test and calculate relation size.
test_size_copy   --> run copy test and relation size
copy_script  -> copy pg_bench script used by test_size_copy.sh
insert_script --> insert pg_bench script used by test_size_ins.sh
multi_extend_v14_poc_v1.patch --> modified patch of v14.

I also tried modifying v14 from different different angle.

One is like below-->
In AddExtraBlock
   I add page to FSM one by one like v13 does.
   then update the full FSM tree up till root

1. With this performance is little less than v14 but the problem of extra
relation size is solved.
2. With this we can conclude that extra size of relation in v14 is because
some while extending the pages, its not immediately available and at end
some of the pages are left unused.

Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Attachment: test_size_copy.sh
Description: Bourne shell script

Attachment: test_size_ins.sh
Description: Bourne shell script

Attachment: copy_script
Description: Binary data

Attachment: insert_script
Description: Binary data

Attachment: multi_extend_v14_poc_v1.patch
Description: Binary data

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

Reply via email to