Re: Relation extension scalability - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Relation extension scalability
Date
Msg-id CAFiTN-t5ELpH6g_8QhAc3VeG_3BhbFkuqUuGqzZYV=-qDrqLuQ@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

On Wed, Mar 30, 2016 at 7:19 AM, Robert Haas <robertmhaas@gmail.com> wrote:

Thanks for review and better comments..
 
hio.c: In function ‘RelationGetBufferForTuple’:
hio.c:231:20: error: ‘freespace’ may be used uninitialized in this
function [-Werror=uninitialized]
hio.c:185:7: note: ‘freespace’ was declared here
hio.c:231:20: error: ‘blockNum’ may be used uninitialized in this
function [-Werror=uninitialized]
hio.c:181:14: note: ‘blockNum’ was declared here

I have fixed those in v20

 

There's nothing whatsoever to prevent RelationExtensionLockWaiterCount
from returning 0.

It's also rather ugly that the call to UpdateFreeSpaceMap() assumes
that the last value returned by PageGetHeapFreeSpace() is as good as
any other, but maybe we can just install a comment explaining that
point; there's not an obviously better approach that I can see.

Added comments..
 
+ if (lockWaiters)
+ /*
+ * Here we are using same freespace for all the Blocks, but that
+ * is Ok, because all are newly added blocks and have same freespace
+ * And even some block which we just added to FreespaceMap above, is
+ * used by some backend and now freespace is not same, will not harm
+ * anything, because actual freespace will be calculated by user
+ * after getting the page.
+ */
+ UpdateFreeSpaceMap(relation, firstBlock, blockNum, freespace);


Does this look good ?

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

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Updated backup APIs for non-exclusive backups
Next
From: Tom Lane
Date:
Subject: Re: Please correct/improve wiki page about abbreviated keys bug