> > [EMAIL PROTECTED] wrote: > >>The best phrasing would be "the accumulating overhead of deletes and >>updates." >> >>Yes. >> >> > > Are you using 7.3? > > I am asking because in 7.3 high update / delete tables could suffer > (index and toast) bloat that was untamable via (lazy) VACUUM and FSM. > I believe this is fixed in 7.4, so it should be possible to achieve on > disk size control of tables / indexes by configuring FSM and (lazy) > VACUUM. Did you find this not to be the case? > Interesting, the company is usng 7.3.4. One single row summary table got up to 2 million dead rows. A select from that single row took a quarter of a second. A regular vacuum did not fix it, only a vacuum full did. However, when the test was re-run with constant vacuums, it did not get out of hand.
My concern is performance, and yes, for inserts PostgreSQL is great. For data that is constantly being updated, PostgreSQL is a bit weak. Think about a table with a few million rows that needs to be updated a few thousand times a minute. I love PG, I've been using it since version 6x, and it has gotten fantastic over the years, and in many cases, I would choose it over Oracle, but for systems that need frequent updates, I have a lot of concerns. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
