Greg Williamson wrote:
running transactions can cause autovacuum processes to stall
out or be autocancelled. Long running transactions - is now
long? In our system it's rare to have a transaction (even a
prepared transaction) last much longer than a few minutes. Is
that enough time to cause
The good news is that we have now resolved our critical problem (disk
space overuse) with a somewhat hackish, slow answer that is nonetheless
good enough for now.
Now I'd like to work out how to get autovacuum to work smoothly within
our cluster. I'm happy to try to clarify my notes and post
Lists wrote:
There's a wealth of how to tune PG instruction that's old and
(based on this thread alone) often stale enough to be classified
as disinformative. For example, nearest I can tell, the entirety of
this page is just wrong and/or irrelevant for 9.x and up:
Kevin --
You wrote:
...
running transactions can cause autovacuum processes to stall
out or be autocancelled. Long running transactions - is now
long? In our system it's rare to have a transaction (even a
prepared transaction) last much longer than a few minutes. Is that
enough time to cause
On 11/13/2012 04:04 AM, Lists wrote:
There's a wealth of how to tune PG instruction that's old and (based
on this thread alone) often stale enough to be classified as
disinformative. For example, nearest I can tell, the entirety of this
page is just wrong and/or irrelevant for 9.x and up:
On 11/13/2012 10:29 AM, Craig Ringer wrote:
On 11/13/2012 04:04 AM, Lists wrote:
There's a wealth of how to tune PG instruction that's old and (based
on this thread alone) often stale enough to be classified as
disinformative. For example, nearest I can tell, the entirety of this
page is
Chander Ganesan wrote:
Jeremy Harris wrote:
Version:
PostgreSQL 8.2.4 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20070418 (Red Hat 4.1.2-10)
We have one problematic table, which has a steady stream of entries
and a weekly mass-delete of ancient history. The bloat query from
Jeremy Harris wrote:
Chander Ganesan wrote:
Inserts don't generate dead tuples, and AVD looks at obsolete
tuples.. As such, I wouldn't expect AVD to kick off until after you
did a mass delete...assuming that delete was sizable enough to
trigger a vacuum.
Ah, that would explain it -
Jeremy Harris wrote:
Hi,
We're starting to run autovacuum for the first time on a system
that's been running with nightly cron-driven vacuum for some time.
Version:
PostgreSQL 8.2.4 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20070418 (Red Hat 4.1.2-10)
We have one
Hi,
We're starting to run autovacuum for the first time on a system
that's been running with nightly cron-driven vacuum for some time.
Version:
PostgreSQL 8.2.4 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2
20070418 (Red Hat 4.1.2-10)
We have one problematic table, which has a
On Jan 28, 2008 10:17 PM, Jeremy Harris [EMAIL PROTECTED] wrote:
Hi,
We're starting to run autovacuum for the first time on a system
that's been running with nightly cron-driven vacuum for some time.
Version:
PostgreSQL 8.2.4 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2
Christopher Browne wrote:
Is it possible that this table didn't see many updates, today?
Nope; about 24000 (according to the id sequence).
- Jeremy
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
On Mon, 2008-01-28 at 22:17 +, Jeremy Harris wrote:
We have one problematic table, which has a steady stream of entries
and a weekly mass-delete of ancient history. The bloat query from
Greg Sabino Mullane (thanks to Greg Smith for pointing it out) returns:
schemaname | tablename |
On Tue, 29 Jan 2008, Ow Mun Heng wrote:
Can you let me know what is the sql used to generate such a nice summary
of the tables?
Might as well dupe the old text; this went out to the performance list:
Greg Sabino Mullane released a Nagios plug-in for PostgreSQL that you can
grab at
On Mon, 2008-01-28 at 20:57 -0500, Greg Smith wrote:
On Tue, 29 Jan 2008, Ow Mun Heng wrote:
Can you let me know what is the sql used to generate such a nice summary
of the tables?
Might as well dupe the old text; this went out to the performance list:
Greg Sabino Mullane released a
15 matches
Mail list logo
