Jeff Janes <jeff.ja...@gmail.com> writes:
> On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra <t...@fuzzy.cz> wrote:
>> Ummmm, what you mean by "catalog bump"?
> There is a catalog number in src/include/catalog/catversion.h, which
> when changed forces one to redo initdb.
> Formally I guess it is only for system catalog changes, but I thought
> it was used for any on-disk changes during development cycles.
Yeah, it would be appropriate to bump the catversion if we're creating a
new PGDATA subdirectory.
I'm not excited about keeping code to take care of the lack of such a
subdirectory at runtime, as I gather there is in the current state of
the patch. Formally, if there were such code, we'd not need a
catversion bump --- the rule of thumb is to change catversion if the new
postgres executable would fail regression tests without a run of the new
initdb. But it's pretty dumb to keep such code indefinitely, when it
would have no more possible use after the next catversion bump (which is
seldom more than a week or two away during devel phase).
>> What do you mean by "stats collector activity"? Is it reading/writing a
>> lot of data, or is it just using a lot of CPU?
> Basically, the launching of new autovac workers and the work that that
> entails. Your patch reduces the size of data that needs to be
> written, read, and parsed for every launch, but not the number of
> times that that happens.
It doesn't seem very reasonable to ask this patch to redesign the
autovacuum algorithms, which is essentially what it'll take to improve
that. That's a completely separate layer of code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
