Josh Berkus writes:
> Yes, but it will have less of an impact on the system while it's running.
We'll find out. I lowered it to vacuum_mem to 32000.
> What sort of disk array do you have? That seems like a lot of time
> considering how little work VACUUM is doing.
Vendor: DELL Model: PE
Manfred Koizar writes:
> ISTM you are VACCUMing too aggressively. You are reclaiming less than
> 1% and 0.005%, respectively, of tuples. I would increase FSM settings
> to ca. 1000 fsm_relations, 10 fsm_pages and VACUUM *less* often,
> say every two hours or so.
I did this. We'll see how it
Friday, October 17, 2003 12:05, Tom Lane [mailto:[EMAIL PROTECTED] wrote:
>Murthy Kambhampaty <[EMAIL PROTECTED]> writes:
>> ... The script handles situations
>> where (i) the XFS filesystem containing $PGDATA has an
>external log and (ii)
>> the postmaster log ($PGDATA/pg_xlog) is written to a
There's been a lot of discussion on the ADMIN list about postgresql backups
from LVM snapshots:
http://marc.theaimsgroup.com/?l=postgresql-admin&w=2&r=1&s=LVM+snapshot&q=b
Note that the existence of the snapshot slows the original filesystem down,
so you want to minimize the duration for which the
On Fri, 17 Oct 2003 09:52:26 -0600, Rob Nagler <[EMAIL PROTECTED]>
wrote:
>INFO: Removed 8368 tuples in 427 pages.
>CPU 0.06s/0.04u sec elapsed 1.54 sec.
>INFO: Pages 24675: Changed 195, Empty 0; Tup 1031519: Vac 8368, Keep 254, UnUsed
>1739.
>Total CPU 2.92s/2.58u sec elapsed 65
Rob,
> vacuum_mem might be slowing down the system? But if I reduce it,
> won't vacuuming get slower?
Yes, but it will have less of an impact on the system while it's running.
> INFO: Removed 8368 tuples in 427 pages.
> CPU 0.06s/0.04u sec elapsed 1.54 sec.
> INFO: Pages 24675: Change
Murthy Kambhampaty <[EMAIL PROTECTED]> writes:
> ... The script handles situations
> where (i) the XFS filesystem containing $PGDATA has an external log and (ii)
> the postmaster log ($PGDATA/pg_xlog) is written to a filesystem different
> than the one containing the $PGDATA folder.
It does? How
Shridhar Daithankar writes:
> You should try 7.4 beta and pg_autovacuum which is a contrib module
> in CVS tip.
It's on our todo list. :)
How does pg_autovacuum differ from vacuumdb? I mean it seems to call
the vacuum operation underneath just as vacuumdb does. I obviously
didn't follow the lo
> Any suggestions how to make vacuuming more effective and reducing the
> time it takes to vacuum? I'd settle for less frequent vacuuming or
> perhaps index rebuilding. The database can be re-imported in about an
> hour.
Which version and what are your FSM settings?
signature.asc
Description:
Rob Nagler wrote:
It seems a simple "vacuum" (not full or analyze) slows down the
database dramatically. I am running vacuum every 15 minutes, but it
takes about 5 minutes to run even after a fresh import. Even with
vacuuming every 15 minutes, I'm not sure vacuuming is working
properly.
There ar
It seems a simple "vacuum" (not full or analyze) slows down the
database dramatically. I am running vacuum every 15 minutes, but it
takes about 5 minutes to run even after a fresh import. Even with
vacuuming every 15 minutes, I'm not sure vacuuming is working
properly.
There are a lot of updates
11 matches
Mail list logo
