Re: how good is PostgreSQL

a) Don't log to a database.  Log data should be sent into a process
   that collects any needed on-the-fly statistics and then outputs
   into disk files (rotating hourly or daily depending on your needs).
   This model is becoming pretty standard with Apache now; look at
   rotatelog in the Apache distribution for an example.

b) Number of records isn't really the issue.  Query complexity and
   number of queries are more pertinent.  Generally, for example, a
   single SELECT that pulls in multiple rows is much faster than
   a bunch of small SELECTs.

c) For very high traffic, you are going to have multiple front-end
   servers.  If you design the system carefully, you can have a single
   shared network disk used by all of your front ends, then just stack
   boxes in front of it.  This doesn't give you endless scalability,
though;
   at some point you'll saturate your network file server and/or
database
   box.

d) PHP may not be a great choice.  It doesn't provide a lot of hooks
   for effective caching of database connections and/or results.
   mod_perl or Java servlets may be better, depending on the details.

                - Tim Kientzle

Arnold Gamboa wrote:
>
> Hi,
>
> For users of large PostgreSQL and PostgreSQL builders, this is for you.
>
> I'm having a terrible time deciding now. :(
>
> We're about to build a "huge" website now.  I got tied up in signing the
> contract without really getting enough information about PgSQL since this
> what we plan to implement with PHP (normally we use mySQL but i guess it
> does not fit for huge databases like that).
>
> Here's my problem.. We're about to build a site like hitbox.com where there
> is a large amount of database required.. If say there is 100,000 users with
> 1000 page hits per day for each, and everything will be logged, you could
> imagine how huge this will be.  I'm just so "nervous" (really, that's the
> term) if we implement this and later on experience a slow down or worse than
> that, crash in the server.
>
> My questions are:
> 1. What is the limit for number of records in a table WITHOUT SUFFERING SLOW
> DOWN.
> 2. ....limit in number of tables per database
> 3. ... limit in number of database.
>
> Thanks for you comments.  I would really appreciate every comment that I'll
> receive regarding this.
>
> Arnold