Gregory Stark wrote: > "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes: > >> some additional datapoints: >> >> autovacuum on, delay 20: 8h 40min >> autovacuum on, delay 0: 4h 23min > > > I realize this isn't directly addressing the problem but perhaps part of the > solution would be to start advocating the use of pg_restore -1 ? That would > solve the problem for the narrow case of pg_restore. > > In the long run we could think about exposing some kind of command for > pg_restore to use which would disable autovacuum from touching a table. (Or > take a session-level lock on the table -- shudder)
In my opinion, CREATE INDEX shouldn't need to wait for autovacuum to finish, regardless of who issued it. This is like priority inversion; the autovacuum is not urgent, and runs slowly to avoid disturbing others. But if it keeps the higher priority CREATE INDEX from starting, it is disturbing others. Could we arrange things so that the effective cost delay of the autovacuum process that's in the way gets set to 0 (like priority inheritance)? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
