Re: reducing statistics write overhead - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: reducing statistics write overhead
Date
Msg-id 20090122220037.GM4296@alvh.no-ip.org
Whole thread Raw
In response to Re: reducing statistics write overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: reducing statistics write overhead  (Euler Taveira de Oliveira <euler@timbira.com>)
List pgsql-hackers
Tom Lane escribió:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Martin Pihlak escribi�:
> >> [ patch to fool with stats refresh logic in autovac ]
> 
> (1) I still don't understand why we don't just make the launcher request
> a new stats file once per naptime cycle, and then allow the workers to
> work from that.

The problem is workers that spend too much time on a single database.
If the stats at the time they both start say that a given table must be
vacuumed (consider for example that the first one spent too much time
vacuuming some other big table), they could end up both vacuuming that
table.  The second vacuum would be a waste.

This could be solved if the workers kept the whole history of tables
that they have vacuumed.  Currently we keep only a single table (the one
being vacuumed right now).  I proposed writing these history files back
when workers were first implemented, but the idea was shot down before
flying very far because it was way too complex (the rest of the patch
was more than complex enough.)  Maybe we can implement this now.

> (2) The current code in autovacuum.c seems to be redundant with the
> logic that now exists in the stats mechanism itself to decide whether a
> stats file is too old.

Hmm, yeah, possibly.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Upcoming back-branch re-releases
Next
From: Tom Lane
Date:
Subject: Re: autovacuum, reloptions, and hardcoded pg_class tupdesc