On Mon, Mar 28, 2016 at 7:21 AM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> I agree with that conclusion. I'm not quite sure where that leaves >> us, though. We can go back to v13, but why isn't that producing extra >> pages? It seems like it should: whenever a bulk extend rolls over to >> a new FSM page, concurrent backends will search either the old or the >> new one but not both. >> > Our open question was why V13 is not producing extra pages, I tried to print some logs and debug. It seems to me that, when blocks are spilling to next FSM pages, that time all backends who are waiting on lock will not get the block because searching in old FSM page. But the backend which is extending the pages will set RelationSetTargetBlock to latest blocks, and that will make new FSM page available for search by new requesters. 1. So this is why v13 (in normal cases*1) not producing unused pages. 2. But it will produce extra pages (which will be consumed by new requesters), because all waiter will come one by one and extend 512 pages. *1 : Above I have mentioned normal case, I mean there is some case exist where V13 can leave unused page, Like one by one each waiter Get the lock and extend the page, but no one go down till RelationSetTargetBlock so till now new pages are not available by new requester, and time will come when blocks will spill to third FSM page, now one by one all backends go down and set RelationSetTargetBlock, and suppose last one set it to the block which is in 3rd FSM page, in this case, pages in second FSM pages are unused. Maybe we could do this - not sure if it's what you were suggesting above: >> >> 1. Add the pages one at a time, and do RecordPageWithFreeSpace after each >> one. >> 2. After inserting them all, go back and update the upper levels of >> the FSM tree up the root. >> > I think this is better option, Since we will search last two pages of FSM > tree, then no need to update the upper level of the FSM tree. Right ? > > I will test and post the result with this option. > I have created this patch and results are as below. * All test scripts are same attached upthread 1. Relation Size : No change in size, its same as base and v13 2. INSERT 1028 Byte 1000 tuple performance ----------------------------------------------------------- Client base v13 v15 1 117 124 122 2 111 126 123 4 51 128 125 8 43 149 135 16 40 217 147 32 35 263 141 3. COPY 10000 Tuple performance. ---------------------------------------------- Client base v13 v15 1 118 147 155 2 217 276 273 4 210 421 457 8 166 630 643 16 145 813 595 32 124 985 598 Conclusion: --------------- 1. I think v15 is solving the problem exist with v13 and performance is significantly high compared to base, and relation size is also stable, So IMHO V15 is winner over other solution, what other thinks ? 2. And no point in thinking that V13 is better than V15 because, V13 has bug of sometime extending more than expected pages and that is uncontrolled and same can be the reason also of v13 performing better. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
multi_extend_v15.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
