On Tue, 2008-06-10 at 11:02 +0530, Pavan Deolasee wrote:
> In most of the cases where the old transactions quickly go away, and
> for large tables, the second scan will be very limited. In the worst
> case, we might incur the overhead of conditional waits without any
> success.
Looks good.
> - An additional boolean pg_class attribute (relvac_inprogress) is used
> to track the status of vacuum on a relation. If the attribute is true,
> either vacuum is in progress on the relation or the last vacuum did
> not complete successfully.
>
> When VACUUM starts, it sets relvac_inprogress to true.
What happens if the last VACUUM crashed? Any negative effects? If so,
should autovac be triggered again soon to complete the failed VACUUM?
> - We can potentially update FSM at the end of first pass. This is not
> a significant issue if the second scan is very limited. But if we do
> this, we need to handle the truncate case properly.
Not sure why would we do that? What would that give? To do that you'd
need to completely redesign FSM since it assumes only one update would
take place.
> - As the patch stands, we check of old transactions at every block
> iteration. This might not be acceptable for the cases where there are
> long running transactions. We probably need some exponential gap here.
I would make vacuum_delay_point() return bool rather than void, then you
can do the check each time we do the delay by saying:
if (vacuum_delay_point())
{
Need to change VacuumCostActive so it is always active during a VACUUM,
so we do accounting even when vacuum wait is zero.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
