On Tue, 16 Mar 2004 15:14:59 -0500 Wade Chandler <wchandler@xxxxxxxxxxxxxxx> wrote:
> Richard Welty wrote:
> > On Tue, 16 Mar 2004 12:51:51 -0500 Wade Chandler <wchandler@xxxxxxxxxxxxxxx> wrote:
> >
> >>If you need a full blown server it is much cheeper than other
> >>alternatives...except for Firebird DBMS.
> >
> >
> > PostgreSQL?
> >
> > richard
> I like PostgreSQL as far as it's simplicity and things go. It's nice,
> and there are some good front ends for it. The one complaint I have
> with Postgres is that it forks.
> MySQL and Firebird use threads and Postgres forks. Forking is ok,
> unless you have many database connections. The more connections the
> more processes. I noticed while profiling an application that every
> connection alone was taking over 1MB of memory. This based on the
> process per connection gripe I have.
> So, Postgres, sure I like it, but as far as a major DBMS goes, I think
> it is limited by it's memory usage. That's just my opinion on the
> matter.
1M per process seems like trivia, quite frankly, given that single
purpose RDBMS systems typically get 1/2G or 1G of RAM these
days.
the PostgreSQL counterargument is that there is a lot variation in
threading mechanisms, and developer time spent on threading is
developer time that isn't going into, say, the query planner.
> However, it is a fact that it forks (forking takes more time
> and more resources than threading). One benefit in forking is the same
> reason Apache forks( memory leaks can be minimized). However, I think
> if a DBMS has that bad of a memory leak....I won't use it.
that's a strawman, in that it's not why PostgreSQL forks (and i'm not aware
of any memory leak issues in PostgreSQL anyway.)
for resource consumption, you should think more in terms the time cost
in forking vs threading -- but in any event, connecting to an SQL database,
whether it forks or threads, is expensive, which is why for large scale
deployments we all get told, time and time again, to use connection
pooling if we want to live.
if you don't want to code your own connection pooling, fine, that's
why we have SQL relay.
richard
--
Richard Welty rwelty@xxxxxxxxxxxxxxx
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
