Guillaume Smet wrote: > On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote: >> Please try that experiment with all three configurations on both >> versions: >> * autovacuum off >> * autovacuum on, autovacuum_vacuum_cost_delay = 0 >> * autovacuum on, autovacuum_vacuum_cost_delay = 20 > > I've finally found some time to spend on these tests. Here are the results: > > * 8.2.5 * > - autovacuum off + ANALYZE: less than 16 minutes (figures previously > posted in this thread) - default configuration of 8.2 > - autovacuum on, delay 0: 16m29 > - autovacuum on, delay 20: 16m13 > (I didn't repeat the run but we can see that autovacuum doesn't > introduce too much slowdown during the restore operation) > > * 8.3devel freshly compiled * > - autovacuum off: 14m39 > - autovacuum on, delay 0: 15m32 > - autovacuum on, delay 20: 51m37 (the box is idle during a large > amount of this time) - default configuration of 8.3devel
some additional datapoints: autovacuum on, delay 20: 8h 40min autovacuum on, delay 0: 4h 23min for restoring a database of around 120GB (on disk size) ... In the delay 20 case the restore is more or less waiting hours for grabbing locks during PK creation held by autovacuum (which tries to analyze the tables). Stefan ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
