On Thursday, 20 March 2014 2:45 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >On Wed, Mar 19, 2014 at 6:25 AM, Wang, Jing <ji...@fast.au.fujitsu.com> wrote: >> On Friday, 14 March 2014 2:42 PM, Amit Kapila <amit.kapil...@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 a message for index in this patch, >>> but similar information could be useful there as well to suggest a user >>> that index has lot 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 burden increasing. 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 information based 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 existing patch is better. Cause the number of pages of FSM file is small , calculating FreeSpace for small table will not bring 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 might be 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
