Ok.Inability to customize thresholds on a per table basis
This hasn't been a big problem for me. I would judge that 80% of my clients would make no use of this feature.
So interesting, most uses request the per table settings, guess there is sufficient demand for both.Inability to set default thresholds on a per database basis
This would be much more useful to us.
You might be missing the point, the advantage of using pg_autovacuum is that it wouldn't waste cycles doing vacuums on tables that don't need it. If we have persistent data (saving state information periodically) then this is a very easy feature to add.Inability to schedule vacuums during off-peak times
I don't think that this is the job of pg_autovacuum. If a database requires bulk loads and other burst activity, the DBA should schedule manual vacuums around those and not use pg_autovacuum.
Yes, backend integration will make this go away.Lack of integration related to startup and shutdown
Yes, this is a pain, especially from a security standpoint.
What I'm thinking is that the VACUUM command could be modified to write down some data from the stats system at vacuum time. Once the VACUUM command writes this down for itself then pg_autovacuum just uses that number to make its decision. Again, we are trying to reduce as much as possible superfluous vacuums. If an admin vacuums his whole cluster every Sunday night that may prevent lots of vacuums occurring during business hours that effect processing.Ignorance of VACUUM and ANALYZE operations performed outside pg_autovacuum(requires backend integration? or can listen / notify can be used?)
Again, I think this is not crucial, personally. Nice if there's some easy way to do it, of course.
Agreed. This is another issue that could be solved with backend integration.Lack of logging options / syslog integration / log rotation options
Yep, this is a biggie.
Now, let me add my comments as to what my clients have complained about:Backend integration should solve the 1st issue. Parallel vacuums is something that could be worked on at some point. Would it make sense to incorporate this with tablespaces? The vacuum daemon would only issue one vacuum command per tablespace, but could issue as many parallel vacuums as you have independent tablespaces.
-- Lack of integrated security with the Postmaster
-- Inability to detect VACUUMs "backing up" due to too low vacuum mem or too much activity and warn the DBA
-- Inability to Vacuum in parallel on high-capacity machines
-- No "timeout" for locked vacuums.
I think timeout issue would need to be a part of vacuum proper, and I'm not sure about the "backing up" issue.
I think I was unclear, I agree the creation of a pg_autovacuum system table is fine (if we really need it), but my initial post was talking about keeping pg_autovacuum as a client app, hence the autovacuum table would be added into (clutter up) the users table space, not the systems.Since many people do not like tools that clutter their databases by addingtables, I think option 1 (adding a pg_autovacuum table to existing databases) is right out.
Personally, I like the idea of a pg_autovacuum table, and would supporrt it. However, I have no strong objections to the other approaches.
I think we've already had feedback about this. If it's system information, it should go in one of the existing tables, or it should be called something more descriptive than "table_data", and should begin with pg_I wasn't really suggesting table_data as the real name, but again this will be more straightforward once integrated in.
Some consideraiton should also be given to the frequency of updating the persistent data. I would favor an asynchnous, infrequent updating that would permit some loss of information over a synchrnous lossless approach. The latter, while more accurate, would detract from server performance on high-volume transction databases.Agreed, the performance impact of this should be negligible.
The reason it's similar is that once pg_autovacuum data is persistent, it would be trivial to implement this feature, and the data that any tool would need to make these decisions is the same as what pg_autovacuum is already tracking.3.Single-Pass Mode (External Scheduling):I think this is a completely different utility from pg_autovacuum, and this line of development need not be pursued unless it's easy to do. I certainly don't need it ....
I have received requests to be able to run pg_autovacuum only on request
I think the patch was submitted to either the hackers or patches list. If you can't find it, I'll look around and see if I still have a copy. The person who submitted said it was simple, but was working for him in production.Syslog support. I'm not sure this is really needed, but a simple patch wasI need it, and am glad to hear there is a patch. Several of my clients use centralized syslog servers, and do *everything* through syslog.
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
