Re: HOT patch, missing things

On 8/7/07, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> wrote:
>
> There's three things clearly missing in the patch:

Yes, these are the major ones, though we might want to play with
the chain pruning, FSM handling and other smaller things to see
if there are any performance benefits.

1. HOT updates on tables with expression or partial indexes. Hasn't been
> done yet because it should be pretty straightforward and we've had more
> important things to do. Though not critical, should be finished before
> release in my opinion.

I agree. I personally haven't had chance to look into this. But I can
do that now if we think that rest of the patch is in a good shape and
there are no other high priority items left.

2. Pointer swinging. At the moment, after a row is HOT updated, the only
> way to get rid of the redirecting line pointer is to run VACUUM FULL or
> CLUSTER (or delete or cold update the row and vacuum). If we want to
> implement pointer swinging before release, we have to get started now.
> If we're happy to release without it and address the issue in later
> releases if it seems important, we need to make a conscious decision on
> that, now. I personally think we can release without it.

I am personally not to much bothered about it. Not just because its
4 bytes per HOT chain we are talking about, but there would be time
when the tuple is COLD updated and the redirection in the old chain
would get reclaimed in the normal vacuum. I am very pleased with the
very little complexity left in the code now (and I am sure others would
be too :-))

3. Statistics and autovacuum integration. How should HOT updates be
> taken into account when deciding when to autovacuum and autoanalyze?
> There's a FIXME comment in analyze.c related to this as well. What
> additional statio counters do we need? The patch adds counters for HOT
> updates and for following a HOT chain. Should we have counters for
> pruning and defraging a page as well?

This is something important. For example in the patch as it stands today,
autovacuum is triggered when the number of COLD updates crosses the
vacuum_scale_factor. But because of redirection idea, each COLD update
only results in 4 bytes of dead space (unlike today where the entire
tuple long dead space in created). So we can actually postpone autovacuum
even further.

As Tom pointed out, we might also need to think about how HOT affects
auto analyze etc

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com