Re: Some vacuum & tuning help - Mailing list pgsql-performance

From Matthew T. O'Connor
Subject Re: Some vacuum & tuning help
Date
Msg-id 004901c35b68$8a9d8010$c202a8c0@hplaptop
Whole thread Raw
In response to Re: Some vacuum & tuning help  (Christopher Browne <cbbrowne@libertyrms.info>)
List pgsql-performance
From: "Tom Lane" <tgl@sss.pgh.pa.us>
> "Matthew T. O'Connor" <matthew@zeut.net> writes:
> > I chose to leave pg_autovacuum simple and not add too many features
because
> > the core team has said that it needs to be integrated into the backend
> > before it can be considered a core tool.
>
> I think actually it makes plenty of sense to enhance pg_autovacuum while
> it's still contrib stuff.  My guess is it'll be much less painful to
> whack it around in minor or major ways while it's standalone code.
> Once it's integrated in the backend, making significant changes will be
> harder and more ticklish.  So, now is precisely the time to be
> experimenting to find out what works well and what features are needed.

Fair point, my only concern is that a backend integrated pg_autovacuum would
be radically different from the current libpq based client application.
When integrated into the backend you have access to a lot of information
that you don't have access to as a client.  I know one goal I have for the
backend version is to be based on the FSM and not require the stats
collector since it has a measurable negative effect on performance.

But in the more general sense of learning what features people want
(exclusion lists, per table defaults etc) I agree the current version is a
sufficient testing ground.


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Some vacuum & tuning help
Next
From: Trevor Astrope
Date:
Subject: How Many Inserts Per Transactions