On Wed, 27 Jul 2005, Alvaro Herrera wrote:
> Hackers,
>
> This is a list of things people mentioned as interesting to do for
> vacuum/autovacuum, during the last autovacuum discussion thread. Some
> of them are wishful thinking, others are doable.
>
> Neil, Gavin: both of you mentioned that you didn't like autovacuum as a
> long term solution. May I ask you if you have more suggestions for this
> list?
My argument against autovacuum integration was more about the fact that we
shouldn't automate vacuuming in the backend until the cost of vacuum
reduces significantly. The fact is that it has been integrated so I think
the following might be worth considering:
* Change how we track the need to vacuum
I don't really think the use of row level stats are the best
indicator for a need to vacuum. I wonder if we could keep a
counter for each segment (ie, every 1 GB file backing a heap or
index) or file which indicates the number of blocks which have been
dirtied since the last vacuum. The user would specify a threshold
of X blocks and once we reached that we would invoke vacuum.
This means we can do without row level stats, I think, at the
expense of having to maintain state in shared memory for each
table and index (or segment). I'm not sure if that is a good
trade off or not but it reminds me of counting cards in blackjack
-- and good things always come of that ;-).
That's all I can think of at the moment.
Thanks,
Gavin
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
