Postgres Pro
Downloads
Home   >   mailing lists

Re: Relation extension scalability - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Relation extension scalability
Date
Msg-id CAFiTN-sxgazkW_xmXZ8OE838DV-_ELCni291sCenTDKfzXYiYg@mail.gmail.com
Whole thread Raw
In response to Re: Relation extension scalability  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Relation extension scalability
List pgsql-hackers
Tree view

On Tue, Mar 29, 2016 at 7:26 AM, Robert Haas <robertmhaas@gmail.com> wrote:
Well, it's less important in that case, but I think it's still worth
doing.  Some people are going to do just plain GetPageWithFreeSpace().

I am attaching new version v17.

Its like this...

In RelationAddExtraBlocks
{
    -- Add Block one by one to FSM.
   
    -- Update FSM tree all the way to root
}

In RelationGetBufferForTuple
 ---  Same as v14, search the FSM tree from root.  GetPageWithFreeSpace

Summary:
--------------
1. By Adding block to FSM tree one by one it solves the problem of unused blocks in V14.
2. It Update the FSM tree all they up to root, so anybody search from root can get the block.
3. It also search the block from root, so it don't have problem like v15 has(Exactly identifying which two FSM page to search).
4. This solves the performance problem of V14 by some optimizations in logic of updating FSM tree till root.

Performance Data:
--------------------------
Client  base  v17
--------             --------         --------
1 117 120
2 111 123
4 51 124
8 43 135
16 40 145
32 35 144
64 -- 140
Client  base v17
-------               -------          ------      
1 118 117
2 217 220
4 210 379
8 166 574
16 145 594
32 124 599
64 ---- 609


Notes:
---------
If I do some change in this patch in strategy of searching the block, performance remains almost the same.
 1. Like search in two block like v15 or v17 does.
 2. Search first using target block and if don't get then search from top.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Oleg Bartunov
Date:
Subject: Re: Dealing with collation and strcoll/strxfrm/etc