Re: Firebird and PostgreSQL at the DB Corral.

On Wednesday 17 December 2003 17:07, Paul Ganainm wrote:
> shridhar_daithankar(at)myrealbox(dot)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