Re: Postgres vs Firebird?

LOL!  (thanks)


Redfaced, and going back to check compiler flags,

-- Ross



-----Original Message-----
From: Joshua D. Drake [mailto:jd@commandprompt.com]
Sent: Wednesday, May 04, 2005 3:42 PM
To: Mohan, Ross
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Postgres vs Firebird?


Mohan, Ross wrote:
> while we're on "scalability", any thoughts on needs/plans for 64-bit
> PG?

You mean beyond the fact that we have supported 64-bit for a couple of
years?

Sincerely,

Joshua D. Drake


>
>
>
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Scott Marlowe
> Sent: Wednesday, May 04, 2005 3:19 PM
> To: lists@benjamindsmith.com
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Postgres vs Firebird?
>
>
> On Wed, 2005-05-04 at 13:48, Benjamin Smith wrote:
>
>>As a long-time user of Postgres, (First started using it at 7.0) I'm
>>reading
>>recently that Firebird has been taking off as a database.
>>
>>Perhaps this is not the best place to ask this, but is there any
>>compelling
>>advantage to using Firebird over Postgres? We have a large database (almost
>>100 tables of highly normalized data) heavily loaded with foreign keys and
>>other constraints, and our application makes heavy use of transactions.
>>
>>I say this as my company's growth has been exponential, showing no
>>sign of
>>letting up soon, and I'm reviewing clustering and replication technologies so
>>that we can continue to scale as nicely as we have to date with our single
>>server. (now with a load avg around .30 typically)
>
>
> With some of the changes Tom recently made in the code in CVS,
> PostgreSQL now looks capable of scaling to >4 CPUS (somewhere between
> 8 and 12 is where things start to drop off suddenly) while for
> firebird, handling >1 CPU is a relatively recent development.
>
> I'd say try them both, benchmark them, and see what you think.  But
> keep in mind that you really need to use a 4+ CPU machine to get a
> feel for the scalability of both in a large server environment.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match