On 20 Jun 2005, at 18:46, Josh Berkus wrote:
Alex,
Hi, i'm trying to optimise our autovacuum configuration so that it
vacuums / analyzes some of our larger tables better. It has been set
to the default settings for quite some time. We never delete
anything (well not often, and not much)
Alex,
Downtime is something I'd rather avoid if possible. Do you think we
will need to run VACUUM FULL occasionally? I'd rather not lock tables
up unless I cant avoid it. We can probably squeeze an automated
vacuum tied to our data inserters every now and then though.
As long as your
On 21 Jun 2005, at 18:13, Josh Berkus wrote:
Alex,
Downtime is something I'd rather avoid if possible. Do you think we
will need to run VACUUM FULL occasionally? I'd rather not lock tables
up unless I cant avoid it. We can probably squeeze an automated
vacuum tied to our data inserters
On Tue, Jun 21, 2005 at 11:08:43PM +0100, Alex Stapleton wrote:
Bloody Debian stable. I might have to experiment with building from
source or using alien on debian to convert the rpms. Fun. Oh well.
Or just pull in postgresql-8.0 from unstable; sid is close enough to sarge
for it to work
Hi, i'm trying to optimise our autovacuum configuration so that it
vacuums / analyzes some of our larger tables better. It has been set
to the default settings for quite some time. We never delete
anything (well not often, and not much) from the tables, so I am not
so worried about the
On 20 Jun 2005, at 15:59, Jacques Caron wrote:
Hi,
At 16:44 20/06/2005, Alex Stapleton wrote:
We never delete
anything (well not often, and not much) from the tables, so I am not
so worried about the VACUUM status
DELETEs are not the only reason you might need to VACUUM. UPDATEs
are
Alex Stapleton wrote:
On 20 Jun 2005, at 15:59, Jacques Caron wrote:
...
ANALYZE is not a very expensive operation, however VACUUM can
definitely be a big strain and take a long time on big tables,
depending on your setup. I've found that partitioning tables (at the
application
Alex,
Hi, i'm trying to optimise our autovacuum configuration so that it
vacuums / analyzes some of our larger tables better. It has been set
to the default settings for quite some time. We never delete
anything (well not often, and not much) from the tables, so I am not
so worried about
