On 9/18/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > > * I'm still pretty unhappy about the patch's use of a relcache copy of > GetAvgFSMRequestSize()'s result. The fact that there's no provision for > ever updating the value while the relcache entry lives is part of it, > but the bigger part is that I'd rather not have anything at all > depending on that number.
We could fix the first part by adding relcache invalidation whenever the average FSM request size changes by a certain margin. But I am not insisting on using the avgFSM mechanism to decide when to prune. Perhaps we could > replace that heuristic with something that is page-local; seems like > dividing the total used space by the number of item pointers would give > at least a rough approximation of the page's average tuple size. > > We might get it completely wrong unless we know the number of normal line pointers (redirected, dead and unused line pointers do not take any real storage). Another option would be to prune whenever the free space goes below table fillfactor and hope that users would set fillfactor so that atleast one updated tuple can fit in the block. I know its not best to rely on the users though. But it can be good hint. Yet another option would be to set a hint on the page whenever we fail to do HOT update because of not-enough-free-space in the block. Next time we shall prune and so the subsequent updates would be HOT update. None of these are perfect though. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
