|From:||"Wang, Jing" <jingw(at)fast(dot)au(dot)fujitsu(dot)com>|
|To:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>|
|Cc:||pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>|
|Subject:||Re: issue log message to suggest VACUUM FULL if a table is nearly empty|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Friday, 14 March 2014 2:42 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>On Wed, Mar 12, 2014 at 12:22 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> wrote:
>> On Tue, Mar 11, 2014 at 2:59 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.
|Next Message||Tom Lane||2014-03-19 03:25:08||Re: pg_archivecleanup bug|
|Previous Message||Alexandr||2014-03-19 00:41:35||QSoC proposal: Rewrite pg_dump and pg_restore|