Re: Open issues for HOT patch

On 9/18/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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