Re: Firebird and PostgreSQL at the DB Corral. - Mailing list pgsql-general
From | Shridhar Daithankar |
---|---|
Subject | Re: Firebird and PostgreSQL at the DB Corral. |
Date | |
Msg-id | 200312171857.18958.shridhar_daithankar@myrealbox.com Whole thread Raw |
In response to | Re: Firebird and PostgreSQL at the DB Corral. (Paul Ganainm <paulsnewsgroups@hotmail.com>) |
List | pgsql-general |
On Wednesday 17 December 2003 17:07, Paul Ganainm wrote: > shridhar_daithankar@myrealbox.com says... > > Native Postgresql on windows is practially non-exsitent so if you want to > > compare ease of use, let's talk unix where postgresql is fairly easy to > > use.. > IB/FB is a breeze to use on Unix also - it was developed originally on > Unix machines - it's been around since 1981. Given that FB is a multithreaded application, I wonder how it resolves threading issues across platform. Threading has been discussed here before a lot of times and smacked down because cross platform issues are too much for the trouble worth. (OK this is only one of the reason. The major one is process based architecture works flawlessly anyways..:-)) > > Can that be termed as data corruption due to fault in database server is > > rare. > > Yes. Most issues that crop up on the Interbase and/or Firebird groups > appear to me to be of the "Someone tripped over the power lead on my > machine, and now the db is corrupt" variety - these people also for some > reason appear to have "forced writes" turned off - I think that's like > fsync to you guys. Yes. Additionally IDE disks can never provide guaranteed recovery if write cache is enabled. The issue goes beyond which OS and application it is running.. > OK, I have to be honest here. Some of the terminology used here can > confuse me. Sometimes people use different words for the same thing, and > vice versa. > > What do you mean exactly by extensible data types? And extensible > operators - I'm pretty sure that FB doesn't have those. You can create your own data types and operators which you can later use in table creation and SQL functions etc. See http://developer.postgresql.org/docs/postgres/sql-createoperator.html http://developer.postgresql.org/docs/postgres/sql-createtype.html > > Functions (known in FB as UDF's (User Defined Functions), yes. > > Extensible languages? Care to elaborate? FB can use UDF's in any > language - for example if you write a dll (ARrrhh - Windows again) in > any language of your choice, then it can be used by FB. Well, You should check, http://developer.postgresql.org/docs/postgres/sql-createlanguage.html and http://techdocs.postgresql.org/guides/PLLanguages Particularly, when you have a language handler, you don't need to compile it. e.g. in case of pl/sh, you can type a shell script in create function command and it will work You don't need to compile a function in a shared library unless required..:-) I admit postgresql is bit too much extensible in this respect but who's complaining?..:-) > > > > FB supports approx. 10 major platforms - not quite as many as PG, but > > > still enough to be getting on with. > > > > Practiaclly postgresql supports one platform. Unix..:-) Rest is marketing > > speak. I am not discounting support matrix but I think this is fair to > > start a database comparison. > > All I can say is, if you guys can get a nice, easy Windows setup going, > that will be real progress. Whether you or I like it or not, W$oze is an > important platform. I had a project recently where there is your classic > WNT server in the corner - I suggested putting the db on a cheap (2% of > project cost) Linux box - you should have seen the guy's eyes glaze > over.. it was a non-runner. Problem with windows is it is not Unix where postgresql is easy to port across and windows have some truely brain-dead API's like createProcess(rather absence of fork/exec). It is difficult to port a Unix only software to windows. It is cultural shift and it will take it's own time. Furthermore postgresql developers don't want people to judge stability and ability of postgresql from postgresql on windows. It is expected that postgresql on windows will take quie some time to reach same level of stability on unix in general. That is the reason the port is not rushed upon.. > For the time being, you have to able to offer a *_serious_* Windows > solution. It will come. If one is in a hurry,look elsewhere..:-) I mean what's the point of open source if things are released when they are not ready? > This is one area where FB/IB wins hands down. Absolutely.. > > You didn't cover one thing. The on disk layout. AFAIK, FB uses one > > database per file which makes it hard to support division of data > > physically. > > It's impossible - the server does it for you. Maybe that's part of the > strength *_and_* weakness of IB/FB - it's simplicity. Well, as your database grows it presents problem for performance and scalability I believe. I mean if you have 2000 tables and 400GB of data in single file, how an OS is supposed to guess about caching patterns of data and sync. abilities? Postgresql can get away with syncing small part of cluster which it knows been changed. If a single file has to be synced which is large but change is small, I doubt it will remain efficient for long. > > Postgresql has much better disk organisation IMHO.. > > Sure, but that leads to greater complexity - there's always a quid pro > quo. That is correct but the complexity is already built in, it works and it is proven .So the pain part of it is history and it is time to reap the fruits of some good design efforts..:-) Shridhar
pgsql-general by date: