On Sat, Nov 7, 2009 at 10:19 PM, Scott Marlowe <scott.marlowe at gmail.com>wro=
te:

>
> This an 8 core opteron 2.1GHz machine with 32G ram and a 12 disk RAID-10
> for pgdata and a two disk RAID-1 for pg_xlog.  The autovac when it kicks
> off, since it's set to have a 20 ms cost delay, purposely takes a while, =
so
> as NOT to get in the way.  So, on a 2 to 5Gig table file it can take 10 to
> 20 minutes.  While this is happening, setaddtable is blocked.  While it's
> blocked, all access to the table by other queries are blocked, and nothing
> gets though.  This is NOT a tuning issue on the OS / hardware.  This mach=
ine
> can handle 10 to 20k transactions per minute under normal load.  But the
> interaction between autovac and create set / setaddtable halts all access=
 to
> the table being vacuumed.  The pg_lock and pg_stat_activity show it pretty
> clearly.
>
> However, I can turn off autovac during the create set.  But the create set
> takes wayyyy too long.
>


Note that since it's CPU bound and I have 8 cores, I'm considering breaking
my cerate set up into approx 8 equal sets and create setting all 8 at once,
and each would hit a different core.  This would get my time down to 40
minutes to an hour, and I could just take the application offline if needs
be at 2am.  So it's still workable.  But if there was some simple "alter
function cost 10" type of fix that would rock.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20091107/=
9f0ee677/attachment.htm