Re: Some vacuum & tuning help
От | Matthew T. O'Connor |
---|---|
Тема | Re: Some vacuum & tuning help |
Дата | |
Msg-id | 004901c35b68$8a9d8010$c202a8c0@hplaptop обсуждение исходный текст |
Ответ на | Re: Some vacuum & tuning help (Christopher Browne <cbbrowne@libertyrms.info>) |
Список | 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 по дате отправления: