On 8/7/07, Heikki Linnakangas <heikki@enterprisedb.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