Re: Relation extension scalability
| От | Dilip Kumar |
|---|---|
| Тема | Re: Relation extension scalability |
| Дата | |
| Msg-id | CAFiTN-t5ELpH6g_8QhAc3VeG_3BhbFkuqUuGqzZYV=-qDrqLuQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Relation extension scalability (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Relation extension scalability
|
| Список | 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);
Вложения
В списке pgsql-hackers по дате отправления: