On 17/01/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Try a), b), and c) in order on the offending tables as they address the problem at increasing cost...thanks alot for the detailed information! the entire concept of vacuum isn'tyet that clear to me, so your explanations and hints are very
On Tue, Jan 17, 2006 at 09:14:27AM +0100, Antoine wrote:
think about it - we do very little removing, pretty much only inserts and
selects. I will give it a vacuum full and see what happens.
UPDATES? Remember that, in Postgres, UPDATE is effectively DELETE +
INSERT (from the point of view of
Hi,
We have a horribly designed postgres 8.1.0 database (not my fault!). I
am pretty new to database design and management and have really no idea
how to diagnose performance problems. The db has only 25-30 tables, and
half of them are only there because our codebase needs them (long story,
On Mon, Jan 16, 2006 at 11:07:52PM +0100, Antoine wrote:
performance problems (a programme running 1.5x slower than two weeks
ago) might not be coming from the db (or rather, my maintaining of it).
I have turned on stats, so as to allow autovacuuming, but have no idea
whether that could be
Antoine [EMAIL PROTECTED] writes:
So... seeing as I didn't really do any investigation as to setting
default sizes for storage and the like - I am wondering whether our
performance problems (a programme running 1.5x slower than two weeks
ago) might not be coming from the db (or rather, my
That does sound like a lack-of-vacuuming problem. If the performance
goes back where it was after VACUUM FULL, then you can be pretty sure
of it. Note that autovacuum is not designed to fix this for you: it
only ever issues regular vacuum not vacuum full.
in our db system (for a website), i
[EMAIL PROTECTED] writes:
in our db system (for a website), i notice performance boosts after a vacuum
full. but then, a VACUUM FULL takes 50min+ during which the db is not really
accessible to web-users. is there another way to perform maintenance tasks
AND leaving the db fully operable
in our db system (for a website), i notice performance boosts after a
vacuum
full. but then, a VACUUM FULL takes 50min+ during which the db is not
really
accessible to web-users. is there another way to perform maintenance
tasks
AND leaving the db fully operable and accessible?
You're not
in our db system (for a website), i notice performance boosts after
a vacuum
full. but then, a VACUUM FULL takes 50min+ during which the db is
not really
accessible to web-users. is there another way to perform
maintenance tasks
AND leaving the db fully operable and accessible?
You're not
Try a), b), and c) in order on the offending tables as they address
the problem at increasing cost...
thanks alot for the detailed information! the entire concept of vacuum isn't
yet that clear to me, so your explanations and hints are very much
appreciated. i'll defenitely try these steps
10 matches
Mail list logo
