Re: Why so slow? - Mailing list pgsql-performance

From Bealach-na Bo
Subject Re: Why so slow?
Date
Msg-id BAY101-F38A0FADC87E67C062FE5E1ADB00@phx.gbl
Whole thread Raw
In response to Re: Why so slow?  (Alan Hodgson <ahodgson@simkin.ca>)
Responses Re: Why so slow?  (Bill Moran <wmoran@collaborativefusion.com>)
List pgsql-performance
>If you don't need access to the old data constantly:
>
>  - copy the live data to a new table
>  - TRUNCATE the old table (which needs an exclusive lock but is very fast)
>  - insert the data back in
>  - for an event log I would imagine this could work

Obtaining exclusive locks on this table is very difficult, or rather,
will make life very difficult for others, so I'm averse to running
vacuum full or truncate (though I don't know how fast truncate is)
on a regular basis. I might just get away with running it
once a month, but no more.

(Lazy) vacuum, however is a much more palatable option. But (lazy)
vacuum does not always reclaim space. Will this affect performance and
does this mean that a full vacuum is unavoidable? Or can I get away
with daily (lazy) vacuums?  Disk space is not an issue for me, but
performance is a BIG issue. Of course, I realize that I could improve
the latter with better schema design - I'm working on a new schema,
but can't kill this one yet :|.

Regards,

Bealach



pgsql-performance by date:

Previous
From: "chris smith"
Date:
Subject: Re: Worsening performance with 7.4 on flash-based system
Next
From: Mark Kirkwood
Date:
Subject: Re: Performance Issues on Opteron Dual Core