On Wed, 2007-05-02 at 08:00, Alexander Staubo wrote:
> On 5/2/07, Harpreet Dhaliwal <harpreet.dhaliwal01@gmail.com> wrote:
> > I'm kind of new to postgresql and the project that I'm working on currently
> > deals with parsing emails, storing parsed components in postgresql DB and
> > fire triggers
> > on certain inserts that opens socket connection with a unix tools server,
>
> Are you sure it is a good idea to do this processing synchronously?
> What happens if there is a network problem? It sounds like an
> inefficient and inflexible design.
>
> > I have done alot of homework on this and could think of something like "bulk
> > of data storage in email parsing and how vacuuming it would increase the
> > performance" because i think this vacuum DB concept is not there in other
> > RDBMS.
>
> SQLite also requires vacuuming, as does other databases based on
> MVCC-like designs, although some (eg., Oracle with its redo logs,
> iirc) do their housekeeping behind the scenes.
We're running Oracle 9 here, and it's even worse than vacuuming. Once a
table grows, it stays grown until you rebuild it (you use the move
command, you just don't move it), and if it's filled up it's tablespace,
you have to extend it to get room to do that. On top of that, you can't
move a partitioned table.
I'd say Oracle9 is about 10 times worse than PostgreSQL (any version)
for the amount of manual maintenance it takes to keep it happy.