Re: [PERFORM] PostgreSQL 8.2.3 VACUUM Timings/Performance

2007-03-16 Thread Bruce McAlister
Hi All, Okay, I'm getting a little further now. I'm about to create entries in the pg_autovacuum system tables. However, I'm a little confused as to how I go about finding out the OID value of the tables. The pg_autovacuum table requires the OID of the table you want to create settings for

Re: [PERFORM] PostgreSQL 8.2.3 VACUUM Timings/Performance

2007-03-13 Thread Anton Melser
In fact, getting rid of vacuum full, or changing it to work like cluster, has been proposed in the past. The use case really is pretty narrow; cluster is a lot faster if there's a lot of unused space in the table, and if there's not, vacuum full isn't going to do much so there's not much point

Re: [PERFORM] PostgreSQL 8.2.3 VACUUM Timings/Performance

2007-03-09 Thread Bruce McAlister
Hi Tom, Thanks for the suggestion. It's been a while since I replied to this as I had to go and do some further investigation of the docs with regards the autovacuum daemons configuration. According to the documentation, the formula's for the vacuum and analyze are as follows: Vacuum

Re: [PERFORM] PostgreSQL 8.2.3 VACUUM Timings/Performance

2007-03-05 Thread Heikki Linnakangas
Bruce McAlister wrote: Over time we have noticed increased response times from the database which has an adverse affect on our registration times. After doing some research it appears that this may have been related to our maintenance regime, and has thus been amended as follows: [1]

Re: [PERFORM] PostgreSQL 8.2.3 VACUUM Timings/Performance

2007-03-05 Thread Bruce McAlister
Hi Heikki, Thanks for the reply. The RAID array was implemented due to a projected growth pattern which incorporate all 18 of our databases. The sizings I mentioned only refer to 1 of those databases, which, is also the most heavily used database :) If I understand you correctly, we could in

Re: [PERFORM] PostgreSQL 8.2.3 VACUUM Timings/Performance

2007-03-05 Thread Tom Lane
Bruce McAlister [EMAIL PROTECTED] writes: [1] AutoVacuum runs during the day over the entire PostgreSQL cluster, Good, but evidently you need to make it more aggressive. [2] A Vacuum Full Verbose is run during our least busy period (generally 03:30) against the Database, [3] A Re-Index on

Re: [PERFORM] PostgreSQL 8.2.3 VACUUM Timings/Performance

2007-03-05 Thread Heikki Linnakangas
Aidan Van Dyk wrote: * Heikki Linnakangas [EMAIL PROTECTED] [070305 09:46]: In fact, getting rid of vacuum full, or changing it to work like cluster, has been proposed in the past. The use case really is pretty narrow; cluster is a lot faster if there's a lot of unused space in the table, and

Re: [PERFORM] PostgreSQL 8.2.3 VACUUM Timings/Performance

2007-03-05 Thread Aidan Van Dyk
* Heikki Linnakangas [EMAIL PROTECTED] [070305 09:46]: If that is the case, why would anyone use the vacuum full approach if they could use the cluster command on a table/database that will regen these files for you. It almost seems like the vacuum full approach would, or could, be