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
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
>> p
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:
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
>>> en
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:
> http://wiki.postgresql
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 t
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 - thankyo
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:
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
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 re
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 http://buc
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 | tablenam
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 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
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 ste
15 matches
Mail list logo
