On Friday, 14 March 2014 2:42 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >On Wed, Mar 12, 2014 at 12:22 PM, Haribabu Kommi <kommi.harib...@gmail.com> >wrote: >> On Tue, Mar 11, 2014 at 2:59 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> >>> By the way have you checked if FreeSpaceMapVacuum() can serve your >>> purpose, because this call already traverses FSM in depth-first >>> order to update the freespace. So may be by using this call or >>> wrapper on this such that it returns total freespace as well apart >>> from updating freespace can serve the need. >> >> Thanks for information. we can get the table free space by writing >> some wrapper or modify a little bit of FreeSpaceMapVacuum() function.
> 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. Kind regards Jing Wang Fujitsu Australia
vacuum_v2.patch
Description: vacuum_v2.patch
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
