>>>>> "BL" == Bo Lorentsen <bl@netgroup.dk> writes:
BL> On Tue, 2003-09-02 at 04:08, Vivek Khera wrote:
>> I use it in 24/7/365 system which is heavily written to and read
>> from. The drawbacks I have are:
BL> How depressing, may I ask that PG version you are using ?
Currently 7.2 in production, 7.4b2 in testing on the new system...
>> 1) upgrade to major versions require dump/restore which is a
>> significant amount of downtime for a large DB.
BL> Ok, this is not a thing you do very often, and it would help is we got a
BL> "diff" (since last backup) pg_dump. As one could install the new DB in
BL> parallel with produktion, and then just apply the diff dump on the db
BL> swap.
Well, the thing is for a large DB which is very active, it still
requires significant down-time, since you can't do this 'live'.
>> 2) the need to run vacuum on tables to keep them from bloating too
>> much. on my system which is very busy, sometimes running vacuum
>> pushes the disk beyond its limits and slows the whole system to a
>> crawl.
BL> How often does this vacuum run, and how many delete/updates are there in
BL> between ?
There are *at least* 1 million inserts and 1 million updates per day.
Every two weeks, I purge some old data, which means something like 25
to 30 million rows deleted across several tables (thank $DIETY for
cascade delete).
>> 3) Index bloat is apparently a bigger problem than I thought.
BL> This does not sound too nice !
No, like I said, I shaved 900Mb of index table size this weekend by
re-indexing. Unfortunately it meant I was partially down for about 45
minutes per index on my largest table, and about 15 per index on the
second largest table, and 5 per index on the third largest, then about
90 seconds total for the rest of the tables ;-)
>> If you want commercial support, it is out there. There are at least
>> two companies offering it.
BL> But you have not been unsing any of there services ?
yes. but for a very specific type of support.
