On Thursday, 20 March 2014 2:45 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>On Wed, Mar 19, 2014 at 6:25 AM, Wang, Jing <jingw@fast.au.fujitsu.com> wrote:
>> On Friday, 14 March 2014 2:42 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>> I think it might be okay to even change this API to return the
>>> FreeSpace, as the other place it is used is for Index Vacuum, so even if we don't have any intention to print such
amessage for index in this patch, but similar information could be useful there as well to suggest a user that index
haslot of free space.
>>
>> Enclosed please find the new patch which get the FreeSpace for one relation from the return of FreeSpaceMapVacuum()
function.This function and the fsm_vacuum_page() function have been slightly modified to get the FreeSpace and no I/O
burdenincreasing. The little side-effect is it will calculate FreeSpace for every table even the table is very small.
>I think that can also be avoided, because by the time you call FreeSpaceMapVacuum(), you already have the required
informationbased on which you can decide not to ask for freespace if required.
That will make the function FreeSpaceMapVacuum() look strange and be difficult to understand, so I think keeping the
existingpatch is better. Cause the number of pages of FSM file is small , calculating FreeSpace for small table will
notbring the burden in performance.
>Can't we avoid the new calculation you have added in fsm_vacuum_page(), as this function already updates the size, so
mightbe we can get it from current calculation done in function.
Sorry, I can't find that information from the current calculation. Could you give me some more detail information?
Kind regards
Jing Wang
Fujitsu Australia
