[EMAIL PROTECTED] (Hannu Krosing) writes:
> It also seems that Slony can be modified to not use LISTEN/NOTIFY in
> high load situations (akin to high performance network cards, which
> switch from interrupt driven mode to polling mode if number of packets
> per second reaches certain thresolds).
Y
On Wed, 2005-10-05 at 09:53 +0300, Hannu Krosing wrote:
> On T, 2005-10-04 at 11:10 -0400, Tom Lane wrote:
> > Rod Taylor <[EMAIL PROTECTED]> writes:
> > > The catch is that there are some other very active structures (like
> > > pg_listener for Slony) which after a couple of hours without vacuumin
> > The vacuum ignores vacuum transaction concept looks handy right now.
>
> There is a patch for 8.1 in PATCHES list (postponed to 8.2 :( ). This
> can be backported to 8.0 quite easily.
Understood. I've seen them, but until they're well tested in the newest
version I won't be using them in a pr
Rod Taylor wrote:
> I have maintenace_work_mem set to about 1GB in size.
Isn't a bit too much ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
> > Is it reasonable to cancel and restart the vacuum process
periodically
> > (say every 12 hours) until it manages to complete the work? It takes
> > about 2 hours to do the table scan, and should get in about 10 hours
> > of index work each round.
If we started the vacuum with the indexes,
On T, 2005-10-04 at 00:26 -0400, Rod Taylor wrote:
> As I understand it vacuum operates outside of the regular transaction
> and if you stop it (SIGTERM, or pg_cancel_backend()) some of the work it
> accomplished will be kept when it rolls back.
>
> For large structures with a ton of dead entries
On T, 2005-10-04 at 11:10 -0400, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > The catch is that there are some other very active structures (like
> > pg_listener for Slony) which after a couple of hours without vacuuming
> > will quickly have the DB at an unreasonably high load (low
Rod Taylor <[EMAIL PROTECTED]> writes:
> The catch is that there are some other very active structures (like
> pg_listener for Slony) which after a couple of hours without vacuuming
> will quickly have the DB at an unreasonably high load (low tens) which
> seems to all but halt the vacuum on the la
Rod Taylor <[EMAIL PROTECTED]> writes:
> As I understand it vacuum operates outside of the regular transaction
It's a perfectly normal transaction.
> Is it reasonable to cancel and restart the vacuum process periodically
No.
How big is that table, anyway? Are you trying a VACUUM FULL, or plain
> > Is it reasonable to cancel and restart the vacuum process periodically
>
> No.
>
> How big is that table, anyway? Are you trying a VACUUM FULL, or plain
> vacuum?
It's only about 60GB in size but appears it has been missed for nearly a
month for vacuum and probably has a large percentage de
On Tue, 2005-10-04 at 00:26 -0400, Rod Taylor wrote:
> As I understand it vacuum operates outside of the regular transaction
> and if you stop it (SIGTERM, or pg_cancel_backend()) some of the work it
> accomplished will be kept when it rolls back.
>
> For large structures with a ton of dead entrie
As I understand it vacuum operates outside of the regular transaction
and if you stop it (SIGTERM, or pg_cancel_backend()) some of the work it
accomplished will be kept when it rolls back.
For large structures with a ton of dead entries (which I seem to have a
case), running vacuum takes long enou
12 matches
Mail list logo
