On 23 Lis, 10:23, peterachi...@gmail.com ("Peter Childs") wrote:
> Yes, however....
>
> found x removable
>
> have just been found and are now unused, so on the next run this number will
> be added to the unused unless they get used again in the mean time.
>
> The number ie the unused is the number of tuples left in the free space map
> unused since the last vacuum. If its high it may be worth clustering or
> running vacuum full but only if you don't think you table will never or
> unlikely to grow (insert) or change (update) by less than that number of
> records before you next run vacuum.
>
> Generally only worry if the number is very very high (over 10000).
>
> The best way of understanding the numbers is to run vacuum at regular
> intervals and compare the output.
>
> Peter.
Thank you for your explanation - it's not easy to get help in this
subject... But how it is possible that new unused.
You wrote:
> The number ie the unused is the number of tuples left in the free space map unused since the last vacuum.
This is important information for me but I still can't understand why
this number keeps growing.Correct me if I wrong but if there is 17000
unused tuples in free space map, they should be used in first place
for creating new tuples versions. This should cause that next 17000
operations (consists of INSERT,UPDATE,DELETE) would use fsm for row
version creation instead of creating entirely new tuples at the end of
table file. If I understand it correct number of unused item pointers
should shrink between vacuums (but it still grows)...
Regards
Elmer
