Re: database file size bloat

On Fri, 14 Apr 2000, Brian Neal wrote:

>
> Maybe you might want to try out MySQL?  A little while ago, I compared
> both MySQL and PostgreSQL to see how they stacked up (for my purposes,
> anyway).  I came to the conclusion that while MySQL is a very fast
> read-only database, it doesn't support transactions, row-level locks,
> stored-procedures, sub-selects, etc.  PostgreSQL has a lot more basic
> database support, but it is harder to install and maintain (in my
> opinion), has worse documentation, and a number of interesting
> quirks...for example, the fixed-size row limitation that can only be
> changed by a recompilation, or the VACUUM problem described here.
> Other issues I had included the way the backend seemed to work...it is
> certainly very demanding when it comes to shared memory, and I had
> concerns about the process pool (whether or not pg-sql could handle
> enough connections) instead of threads, which most other databases
> seem to use.

Few commments ... the 'row size limit' should be gone in v7.1, as Jan is
working on implementing TOAST for that ...

AS for the process pool ... there are two camps here ... if you use
threads, when one threads crashes the server, the server is done.  With
forking,if one backend dies, the server is still running ... in a 24x7
shop, I'd rather the solution that doesn't die cause JoeBlow down the hall
blew out something with his query :)