On 7.2.2013 00:40, Tom Lane wrote: > 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
No, there is nothing to handle that at runtime. The directory is created at initdb and the patch expects that (and fails if it's gone). > 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. My opinion, exactly. Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers