On 01/23/2014 07:22 PM, Alvaro Herrera wrote:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by checking load factors or some
other tell-tale of an already-saturated I/O system.
We had a proposed design to tell autovac when not to run (or
On Fri, Jan 24, 2014 at 2:44 PM, Josh Berkus j...@agliodbs.com wrote:
On 01/23/2014 07:22 PM, Alvaro Herrera wrote:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by checking load factors or some
other tell-tale of an already-saturated
On Thu, Jan 23, 2014 at 7:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
I concur with the other reports that the main problem in this test case is
just that the default cost delay settings throttle
Hello,
I have run into yet again another situation where there was an
assumption that autovacuum was keeping up and it wasn't. It was caused
by autovacuum quitting because another process requested a lock.
In turn we received a ton of bloat on pg_attribute which caused all
kinds of other
Joshua D. Drake j...@commandprompt.com writes:
I have run into yet again another situation where there was an
assumption that autovacuum was keeping up and it wasn't. It was caused
by autovacuum quitting because another process requested a lock.
In turn we received a ton of bloat on
On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
Hello,
I have run into yet again another situation where there was an
assumption that autovacuum was keeping up and it wasn't. It was caused
by autovacuum quitting because another process requested a lock.
In turn we received a ton of bloat
On Thu, Jan 23, 2014 at 12:53 PM, Josh Berkus j...@agliodbs.com wrote:
On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
Hello,
I have run into yet again another situation where there was an
assumption that autovacuum was keeping up and it wasn't. It was caused
by autovacuum quitting because
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute? That seems like a pretty unfriendly behavior in itself.
regards, tom lane
I've seen this sort of problem where every db session was busily
creating temporary tables. I never got to the
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on pg_attribute?
That seems like a pretty unfriendly behavior in itself. regards, tom lane
I've seen this sort of
On 01/23/2014 01:03 PM, Mark Kirkwood wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute? That seems like a pretty unfriendly behavior in itself.
regards, tom lane
I've seen this sort of problem where every db session was busily
Dne 23.1.2014 22:04 Mark Kirkwood mark.kirkw...@catalyst.net.nz
napsal(a):
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on pg_attribute?
That seems like a pretty unfriendly behavior in itself. regards, tom lane
I've seen this sort of problem
Mark Kirkwood mark.kirkw...@catalyst.net.nz writes:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute? That seems like a pretty unfriendly behavior in itself.
I've seen this sort of problem where every db session was busily
creating
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on pg_attribute?
That seems like a pretty unfriendly behavior in itself. regards,
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute?
That seems like a pretty
On Thu, Jan 23, 2014 at 10:00 PM, Harold Giménez har...@heroku.com wrote:
On Thu, Jan 23, 2014 at 12:53 PM, Josh Berkus j...@agliodbs.com wrote:
On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
Hello,
I have run into yet again another situation where there was an
assumption that
On 01/23/2014 02:17 PM, Magnus Hagander wrote:
FWIW, I have a patch around somewhere that I never cleaned up properly for
submissions that simply added a counter to pg_stat_user_tables indicating
how many times vacuum had aborted on that specific table. If that's enough
info (it was for my
On 01/23/2014 02:55 PM, Josh Berkus wrote:
On 01/23/2014 02:17 PM, Magnus Hagander wrote:
FWIW, I have a patch around somewhere that I never cleaned up properly for
submissions that simply added a counter to pg_stat_user_tables indicating
how many times vacuum had aborted on that specific
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 24/01/14 09:49, Tom Lane wrote:
2.
On 24/01/14 12:13, Jeff Janes wrote:
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On
On 24/01/14 12:28, Mark Kirkwood wrote:
On 24/01/14 12:13, Jeff Janes wrote:
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
On 2014-01-24 12:49:57 +1300, Mark Kirkwood wrote:
autovacuum_max_workers = 4
autovacuum_naptime = 10s
autovacuum_vacuum_scale_factor = 0.1
autovacuum_analyze_scale_factor = 0.1
autovacuum_vacuum_cost_delay = 0ms
Stops excessive bloat - clearly autovacuum *is* able to vacuum pg_attribute
On 2014-01-23 16:15:50 -0500, Tom Lane wrote:
[ thinks... ] It's possible that what you saw is not the
kick-out-autovacuum-entirely behavior, but the behavior added in commit
bbb6e559c, whereby vacuum (auto or regular) will skip over pages that it
can't immediately get an exclusive buffer
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-23 16:15:50 -0500, Tom Lane wrote:
[ thinks... ] It's possible that what you saw is not the
kick-out-autovacuum-entirely behavior, but the behavior added in commit
bbb6e559c, whereby vacuum (auto or regular) will skip over pages that it
On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
I saw at most two pages skipped per vacuum, and
usually none; so there's no way that a whole lot of tuples are going
unvacuumed because of this. (I wonder though if we ought to add such
counting as a permanent feature ...)
I generally think we
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
I concur with the other reports that the main problem in this test case is
just that the default cost delay settings throttle autovacuum so hard that
it has no chance of keeping up. If I reduce
On 01/24/2014 07:52 AM, Andres Freund wrote:
On 2014-01-24 12:49:57 +1300, Mark Kirkwood wrote:
autovacuum_max_workers = 4
autovacuum_naptime = 10s
autovacuum_vacuum_scale_factor = 0.1
autovacuum_analyze_scale_factor = 0.1
autovacuum_vacuum_cost_delay = 0ms
Stops excessive bloat - clearly
On Thu, Jan 23, 2014 at 10:38 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Stops excessive bloat - clearly autovacuum *is* able to vacuum pg_attribute
in this case. Back to drawing board for a test case.
Well, I think quite many people don't realize it might be necessary to
tune autovac on
Claudio Freire escribió:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by checking load factors or some
other tell-tale of an already-saturated I/O system.
We had a proposed design to tell autovac when not to run (or rather,
when to
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Claudio Freire escribió:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by checking load factors or some
other tell-tale of an already-saturated I/O system.
We had a proposed design to tell
On 01/24/2014 11:32 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Claudio Freire escribió:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by checking load factors or some
other tell-tale of an already-saturated I/O
Craig Ringer escribió:
On 01/24/2014 11:32 AM, Tom Lane wrote:
The hard part of this is that shutting down autovacuum during heavy
load may be exactly the wrong thing to do.
Yep. In fact, it may be appropriate to limit or stop autovacuum's work
on some big tables, while pushing its
On Fri, Jan 24, 2014 at 12:33 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/24/2014 11:32 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Claudio Freire escribió:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by
32 matches
Mail list logo
