Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Greg Smith]

On Thu, 23 Aug 2007, David Fetter wrote:


-Is the Wiki the right place to build this table at?  Large Wiki
tables get very difficult to manage.

They're very easy to manage using things like the Firefox/Mozilla
plugin viewsourcewith



The kind of issues I'm concerned about here is that the normal way to deal 
with Wiki tables is to use the so-called "pipe" syntax for them (see 
http://en.wikipedia.org/wiki/Help:Table ).  That means that any time you 
add a column, you have a laborious process to edit all the rows that are 
already there, and it's really a pain.  And viewsourcewith presumes one 
has a good editor that understands Wiki tables; I'm not aware of one.  Am 
open to ideas if you know of one.


There's an alternate approach that says to treat everything as straight 
HTML tables, then there are all kinds of external editors available that 
can be enabled with a tool like you suggest.  I don't like doing that 
because then it's much harder for people to do spot edits within the 
Wikipedia framework because the harder to read HTML table markup is in 
there.


Another way to go about this is construct the table in a spreadsheet or 
similar grid-oriented application as the primary document, then convert it 
to Wiki format using something like http://area23.brightbyte.de/csv2wp.php 
This is way easier to get an initial table going than any other approach. 
The problem is that it's one-way.


This issue is much bigger than the editing here; if you follow the links 
on Help:Table you can see people have been arguing about how to proceed 
here for years with little progress.  The tables that have been built 
within the developer's wiki so far have been reasonable to maintain 
because more rows get added, but rarely columns.  This feature comparision 
table will be the other way around, which is the harder one to cope with.


--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dave Page]

Harald Armin Massa wrote:
> 
> the SQL Server 2005 Express download provides software that
> 
> is suitable for application embedding or lightweight application
> development.
> 
> 
> I never developed more then some queries on SQL Server Express or its
> different names.
> 
> But I had to work with some applications which used the various
> incarnations of SQL Server Express. And EVERYTIME it was a additionally
> installed application on the system. The only "embedding" that I could
> recognise was the Installer being triggered from the applications
> installer.
> 
> MY idea of an embedded database would be "I link  with my
> software, so that there is only ONE application".
> 
> Is my understaning of "embedded" wrong or oldschool?

SQL CE != SQL Express

SQL CE is the embedded database, SQL Express is a limited version of SQL
Server.

Regards, Dave

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Harald Armin Massa]

>
>
> the SQL Server 2005 Express download provides software that

> is suitable for application embedding or lightweight application
> development.
>

I never developed more then some queries on SQL Server Express or its
different names.

But I had to work with some applications which used the various incarnations
of SQL Server Express. And EVERYTIME it was a additionally installed
application on the system. The only "embedding" that I could recognise was
the Installer being triggered from the applications installer.

MY idea of an embedded database would be "I link  with my
software, so that there is only ONE application".

Is my understaning of "embedded" wrong or oldschool?


Harald
-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
fx 01212-5-13695179
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dave Page]

> --- Original Message ---
> From: "Stephen Ince" <[EMAIL PROTECTED]>
> To: "Dave Page" <[EMAIL PROTECTED]>
> Sent: 27/08/07, 21:30:06
> Subject: Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished
> 
> Dave,
>Thx I will take a look. I was trying to port a postgres schema to a 
> database that had embedded capability. I could not find any non-commerical 
> databases that supported triggers, sequences, udf function, and stored 
> procedure. I as I remembered firebird has pretty weak UDF function 
> capability(only C/C++) and the name size limitation was a killer.
> 

SQL CE is pretty limited as well - no sequences, triggers or udf's either. It 
works very well with .Net CF of course and is a very useful datastore on pocket 
pc device though.
.
Regards, Dave

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dann Corbit]

There are some limitations to SQL Server Express:
http://www.microsoft.com/sql/downloads/trial-software.mspx

Download SQL Server 2005 Express Edition
Complete a SQL Server Express download, free. There are no time limits
and the software is freely redistributable (with registration). With a
database size limit of 4 gigabytes (GB) and support for 1 CPU and up to
1 GB of RAM, the SQL Server 2005 Express download provides software that
is suitable for application embedding or lightweight application
development.

I have never used the CE version and I do not know what the limitations
are.
They are not made clear from the download page:
http://www.microsoft.com/downloads/details.aspx?familyid=B9B12312-FE57-4
817-A4BC-69992802732D&displaylang=en

This document:
http://download.microsoft.com/download/7/f/c/7fc20778-4e2e-4944-b432-ed7
4b404e542/sqlservercompactdatasheet_final.doc

mentions a maximum database size of 4 GB (like the Express version), but
the other limits are not clear.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-general-
> [EMAIL PROTECTED] On Behalf Of Stephen Ince
> Sent: Monday, August 27, 2007 1:30 PM
> To: Dave Page
> Cc: Tony Caduto; Greg Smith; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] PostgreSQL vs Firebird feature comparison
finished
> 
> Dave,
>Thx I will take a look. I was trying to port a postgres schema to a
> database that had embedded capability. I could not find any
non-commerical
> databases that supported triggers, sequences, udf function, and stored
> procedure. I as I remembered firebird has pretty weak UDF function
> capability(only C/C++) and the name size limitation was a killer.
> 
> Steve
> 
> >
> >
> >> --- Original Message ---
> >> From: "Stephen Ince" <[EMAIL PROTECTED]>
> >> To: "Tony Caduto" <[EMAIL PROTECTED]>, "Greg Smith"
> >> <[EMAIL PROTECTED]>, pgsql-general@postgresql.org
> >> Sent: 27/08/07, 17:02:21
> >> Subject: Re: [GENERAL] PostgreSQL vs Firebird feature comparison
> finished
> >>
> >> Postgres can't be embedded or serverless. Firebird has the embedded
> >> feature.
> >> Most of the databases have this capability (hsqldb,
derby,oracle,mysql,
> >> firebird, and db2). Derby and hsqldb are the only free embedded
> databases
> >> for commercial use.
> >>
> >
> > SQL Server CE is also free for commercial use iirc.
> >
> > Regards, Dave
> >
> > ---(end of
broadcast)---
> > TIP 2: Don't 'kill -9' the postmaster
> >
> 
> 
> ---(end of
broadcast)---
> TIP 5: don't forget to increase your free space map settings

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Stephen Ince]

Dave,
  Thx I will take a look. I was trying to port a postgres schema to a 
database that had embedded capability. I could not find any non-commerical 
databases that supported triggers, sequences, udf function, and stored 
procedure. I as I remembered firebird has pretty weak UDF function 
capability(only C/C++) and the name size limitation was a killer.


Steve





--- Original Message ---
From: "Stephen Ince" <[EMAIL PROTECTED]>
To: "Tony Caduto" <[EMAIL PROTECTED]>, "Greg Smith" 
<[EMAIL PROTECTED]>, pgsql-general@postgresql.org

Sent: 27/08/07, 17:02:21
Subject: Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

Postgres can't be embedded or serverless. Firebird has the embedded 
feature.

Most of the databases have this capability (hsqldb, derby,oracle,mysql,
firebird, and db2). Derby and hsqldb are the only free embedded databases
for commercial use.



SQL Server CE is also free for commercial use iirc.

Regards, Dave

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster




---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Stephen Ince]

Point taken for the enterprise comparison. The reason for having the 
embedded database is to hide the complexity for installing, using, and 
configuration of the database from the user of the application. You don't 
want a scaled version of the database.





- Original Message - 
From: "Tony Caduto" <[EMAIL PROTECTED]>

Cc: 
Sent: Monday, August 27, 2007 12:47 PM
Subject: Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished



Stephen Ince wrote:
Postgres can't be embedded or serverless. Firebird has the embedded 
feature. Most of the databases have this capability (hsqldb, 
derby,oracle,mysql, firebird, and db2). Derby and hsqldb are the only 
free embedded databases for commercial use.




A lot of Firebird users have been saying this as well, but the comparison 
if more for Enterprise use.
Plus if you need a embedded database wouldn't it be better to use one 
built specifically for that purpose?  i.e. SQLite for example.


Good call on the name limit, I remember running into that when porting 
something from MS SQL server to Firebird about 4 years ago.

I will have to check and see if this still applies to version 2.0

Later,

Tony

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq




---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Thomas Kellerer]

Stephen Ince wrote on 27.08.2007 18:02:

Derby and hsqldb are the only free embedded databases for commercial use.


Well, there are some more:
H2 Database, OneDollarDB (OpenSource version of DaffodilDB), Berkely DB and 
McKoi are free as well (although McKoi seems to be dead).


Then there are a couple of other Java based engines (SmallSQL, TinySQL, Axioin) 
but they do not compare feature-wise to the "big names".


And of course Firebird is free for commercial use as well.

Thomas


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Scott Marlowe]

On 8/27/07, Stephen Ince <[EMAIL PROTECTED]> wrote:
> I recently ported a schema from postgres to firebird and found name size
> limitations. Firebird has a limitation on the size of it's column names,
> table names, constraint names and index names. I think the size limitation
> on firebird is 31 characters. Postgres doesn't have this limitation.

Note that postgresql does have a limit.  It's just not as short as the
one in firebird.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dave Page]

> --- Original Message ---
> From: "Stephen Ince" <[EMAIL PROTECTED]>
> To: "Tony Caduto" <[EMAIL PROTECTED]>, "Greg Smith" <[EMAIL PROTECTED]>, 
> pgsql-general@postgresql.org
> Sent: 27/08/07, 17:02:21
> Subject: Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished
> 
> Postgres can't be embedded or serverless. Firebird has the embedded feature. 
> Most of the databases have this capability (hsqldb, derby,oracle,mysql, 
> firebird, and db2). Derby and hsqldb are the only free embedded databases 
> for commercial use.
> 

SQL Server CE is also free for commercial use iirc.

Regards, Dave

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Michael Glaesemann]

On Aug 27, 2007, at 11:47 , Tony Caduto wrote:

Good call on the name limit, I remember running into that when  
porting something from MS SQL server to Firebird about 4 years ago.


Just a quick note: PostgreSQL's identifiers are limited to  
NAMEDATALEN - 1 (IIRC), which by default is 64 - 1 = 63 characters:


test=# create table a  
(a23456789112345678921234567893123456789412345678951234567896123 text  
primary key);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index  
"a_pkey" for table "a"

CREATE TABLE
test=# create table b  
(a234567891123456789212345678931234567894123456789512345678961234  
text primary key);
NOTICE:  identifier  
"a234567891123456789212345678931234567894123456789512345678961234"  
will be truncated to  
"a23456789112345678921234567893123456789412345678951234567896123"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index  
"b_pkey" for table "b"

CREATE TABLE

The upshot is that PostgreSQL does have a limit, but it's pretty big  
initially and is configurable at compilation by changing the  
definition of NAMEDATALEN in in src/include/postgres_ext.h.


Michael Glaesemann
grzm seespotcode net



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Tony Caduto]

Stephen Ince wrote:
Postgres can't be embedded or serverless. Firebird has the embedded 
feature. Most of the databases have this capability (hsqldb, 
derby,oracle,mysql, firebird, and db2). Derby and hsqldb are the only 
free embedded databases for commercial use.




A lot of Firebird users have been saying this as well, but the 
comparison if more for Enterprise use.
Plus if you need a embedded database wouldn't it be better to use one 
built specifically for that purpose?  i.e. SQLite for example.


Good call on the name limit, I remember running into that when porting 
something from MS SQL server to Firebird about 4 years ago.

I will have to check and see if this still applies to version 2.0

Later,

Tony

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Stephen Ince]

Postgres can't be embedded or serverless. Firebird has the embedded feature. 
Most of the databases have this capability (hsqldb, derby,oracle,mysql, 
firebird, and db2). Derby and hsqldb are the only free embedded databases 
for commercial use.


I recently ported a schema from postgres to firebird and found name size 
limitations. Firebird has a limitation on the size of it's column names, 
table names, constraint names and index names. I think the size limitation 
on firebird is 31 characters. Postgres doesn't have this limitation.


Steve 



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dave Page]

> --- Original Message ---
> From: Tony Caduto <[EMAIL PROTECTED]>
> To: "Joshua D. Drake" <[EMAIL PROTECTED]>
> Sent: 25/08/07, 15:36:15
> Subject: Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished
> 
> Hi,
> Someone mentioned we should put this in the PostgreSQL wiki.
> 
> Do you guys think that would be beneficial?  If so, I don't mind the 
> work on the list I have done so far going on the wiki.
> It would make it a lot easier to add other DBs to the mix.
>

It's aimed at users, not developers so should go on the community docs section 
of the website, not the wiki.

Regards, Dave

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Tony Caduto]

Greg Smith wrote:



This is a really good comparision, focusing on features that I think 
people understand rather than so much on technical trivia.  Someone 
else mentioned moving it onto the Wiki.  Questions that pop into my head:


-Tony, would be you be comfortable with your work being assimilated 
into a larger table that was hosted somewhere else but credited yours 
as a source?



Thanks Greg :-)

I don't have any problem with what I have done so far being assimilated 
in a larger work as long as I get credited as a contributer.


Later,

Tony

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org/

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Tony Caduto]

Hi,
Someone mentioned we should put this in the PostgreSQL wiki.

Do you guys think that would be beneficial?  If so, I don't mind the 
work on the list I have done so far going on the wiki.

It would make it a lot easier to add other DBs to the mix.

Later,

Tony

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Thomas Kellerer]

Alexander Staubo wrote on 24.08.2007 23:49:

So actually the remark shouldn't be that "the multi-threaded
architecture is only advantageous  on Windows", but more like "the
multi-process architecture is disadvantageous on Windows and hence a
multi-threaded architecture is preferred (on that particular OS)".

Yeah - but I'm not sure thats necessarily something that should have a
place on a bullet point comparison.


You solve it by letting the category be labeled "Process/thread
architecture", and letting the columns say "Thread-based" for Firebird
and "Process-based" for PostgreSQL respectively.


To my understanding Firebird offers a choice between thread-based (Superserver) 
and process-based (Classic) at least on the Windows platform.


Thomas


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Alexander Staubo]

On 8/24/07, Dave Page <[EMAIL PROTECTED]> wrote:
> Alban Hertroys wrote:
> > So actually the remark shouldn't be that "the multi-threaded
> > architecture is only advantageous  on Windows", but more like "the
> > multi-process architecture is disadvantageous on Windows and hence a
> > multi-threaded architecture is preferred (on that particular OS)".
>
> Yeah - but I'm not sure thats necessarily something that should have a
> place on a bullet point comparison.

You solve it by letting the category be labeled "Process/thread
architecture", and letting the columns say "Thread-based" for Firebird
and "Process-based" for PostgreSQL respectively.

Then add a footnote about this row that explains the difference and
how they behave on the different operating systems.

PostgreSQL clearly is at a slight disadvantage on Windows, so this is
relevant, at least to Tony's Delphi-user demographic.

Alexander.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Vivek Khera]

On Aug 24, 2007, at 4:09 AM, Alban Hertroys wrote:


I'm not entirely sure what makes multi-threading be advantageous on a
specific operating system, but I think FreeBSD should be added to that
list as well... They've been bench marking their threading support  
using

multi-threading in MySQL (not for the db, mind you - just for load ;),
and it performs really well.


Maybe only for FreeBSD >= 6.0.  Prior to that, the threading was  
rather lackluster.   I still think the separate process model is  
superior, in that you get private data spaces with them.



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Gregory Stark]

"Dave Page" <[EMAIL PROTECTED]> writes:

> Alban Hertroys wrote:
>> So actually the remark shouldn't be that "the multi-threaded
>> architecture is only advantageous  on Windows", but more like "the
>> multi-process architecture is disadvantageous on Windows and hence a
>> multi-threaded architecture is preferred (on that particular OS)".
>
> Yeah - but I'm not sure thats necessarily something that should have a place 
> on
> a bullet point comparison.

Note that while we use the OS's "threads" api we're not really any more
multi-threaded on Windows than we are on Unix. We don't use any shared memory
data structures we don't on Unix using SysV shared memory, we don't use any
mutexes or other threaded programming techniques that we don't use on Unix,
and so on.

It's purely a question of which API we use to create the threads of execution.
Not an architectural change in Postgres.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dave Page]

Alban Hertroys wrote:

So actually the remark shouldn't be that "the multi-threaded
architecture is only advantageous  on Windows", but more like "the
multi-process architecture is disadvantageous on Windows and hence a
multi-threaded architecture is preferred (on that particular OS)".


Yeah - but I'm not sure thats necessarily something that should have a 
place on a bullet point comparison.


Regards, Dave

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Alban Hertroys]

Dave Page wrote:
> Alban Hertroys wrote:
>> Joshua D. Drake wrote:
 I agree with you on the multi-threaded.  I think I will add a note
 saying the the multi-threaded architecture is only advantageous  on
 Windows.
>>> And Solaris.
>>
>> I'm not entirely sure what makes multi-threading be advantageous on a
>> specific operating system, but I think FreeBSD should be added to that
>> list as well... They've been bench marking their threading support using
>> multi-threading in MySQL (not for the db, mind you - just for load ;),
>> and it performs really well.
>>
> 
> I'm not sure I necessarily agree with those two - we have no real proof
> that a multithreaded architecture would be significantly more efficient
> than a multi process. It certainly wouldn't be as robust as an error in
> one backend thread could bring down the entire server.
> 
> Windows is a special case in this regard. The OS has been designed from
> the outset as a threaded environment. The important point is not that
> Windows threads are necessarily any more efficient than their Solaris or
> FreeBSD counterparts, but that the multi-process architecture is alien
> to Windows and is inherently slower. Two of the major bottlenecks we
> have on Windows as a result are backend startup time and shared memory
> access speed - both of which are significantly slower than on *nix.
> 
> Regards, Dave

Thanks for explaining (again).

So actually the remark shouldn't be that "the multi-threaded
architecture is only advantageous  on Windows", but more like "the
multi-process architecture is disadvantageous on Windows and hence a
multi-threaded architecture is preferred (on that particular OS)".

-- 
Alban Hertroys
[EMAIL PROTECTED]

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
   7500 AK Enschede

// Integrate Your World //

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dave Page]

Alban Hertroys wrote:

Joshua D. Drake wrote:

I agree with you on the multi-threaded.  I think I will add a note
saying the the multi-threaded architecture is only advantageous  on
Windows.

And Solaris.


I'm not entirely sure what makes multi-threading be advantageous on a
specific operating system, but I think FreeBSD should be added to that
list as well... They've been bench marking their threading support using
multi-threading in MySQL (not for the db, mind you - just for load ;),
and it performs really well.



I'm not sure I necessarily agree with those two - we have no real proof 
that a multithreaded architecture would be significantly more efficient 
than a multi process. It certainly wouldn't be as robust as an error in 
one backend thread could bring down the entire server.


Windows is a special case in this regard. The OS has been designed from 
the outset as a threaded environment. The important point is not that 
Windows threads are necessarily any more efficient than their Solaris or 
FreeBSD counterparts, but that the multi-process architecture is alien 
to Windows and is inherently slower. Two of the major bottlenecks we 
have on Windows as a result are backend startup time and shared memory 
access speed - both of which are significantly slower than on *nix.


Regards, Dave

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Alban Hertroys]

Joshua D. Drake wrote:
>> I agree with you on the multi-threaded.  I think I will add a note
>> saying the the multi-threaded architecture is only advantageous  on
>> Windows.
> 
> And Solaris.

I'm not entirely sure what makes multi-threading be advantageous on a
specific operating system, but I think FreeBSD should be added to that
list as well... They've been bench marking their threading support using
multi-threading in MySQL (not for the db, mind you - just for load ;),
and it performs really well.

-- 
Alban Hertroys
[EMAIL PROTECTED]

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
   7500 AK Enschede

// Integrate Your World //

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[David Fetter]

On Thu, Aug 23, 2007 at 03:30:30PM -0400, Greg Smith wrote:
> On Thu, 23 Aug 2007, Tony Caduto wrote:
> 
> >If there is any interest I could also add MySQL 5.0 to the mix as the 
> >third column.
> 
> As already mentioned, MyISAM and InnoDB should get their own columns.

Yes.

> This is a really good comparision, focusing on features that I think 
> people understand rather than so much on technical trivia.  Someone else 
> mentioned moving it onto the Wiki.  Questions that pop into my head:
> 
> -Tony, would be you be comfortable with your work being assimilated into a 
> larger table that was hosted somewhere else but credited yours as a 
> source?
> 
> -Is the Wiki the right place to build this table at?  Large Wiki
> tables get very difficult to manage.

They're very easy to manage using things like the Firefox/Mozilla
plugin viewsourcewith


> It may be easier to build the table in something else and then have
> that generate markup instead.  I'd rather edit this in a spreadsheet
> and write something to massage that into final form than do all the
> edits within the Wikipedia editor.

See above :)

> -If this is going to turn into the grand feature comparision table,
> everyone might as well be thinking from day one that inevitably
> there will be columns for Oracle (with a volunteer to fill out
> already), SQL Server, DB2, etc. and plan a useful way to manage all
> that data from the beginning.  That's another reason why the Wiki is
> a bad way to cope with this data; adding another column is a painful
> and error-prone operation.

Could be.  Try viewsourcewith with your favorite editor and see
whether it eases the pain :)

Cheers,
David.
-- 
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
  Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Greg Smith]

On Thu, 23 Aug 2007, Tony Caduto wrote:

If there is any interest I could also add MySQL 5.0 to the mix as the third 
column.


As already mentioned, MyISAM and InnoDB should get their own columns.

This is a really good comparision, focusing on features that I think 
people understand rather than so much on technical trivia.  Someone else 
mentioned moving it onto the Wiki.  Questions that pop into my head:


-Tony, would be you be comfortable with your work being assimilated into a 
larger table that was hosted somewhere else but credited yours as a 
source?


-Is the Wiki the right place to build this table at?  Large Wiki tables 
get very difficult to manage.  It may be easier to build the table in 
something else and then have that generate markup instead.  I'd rather 
edit this in a spreadsheet and write something to massage that into final 
form than do all the edits within the Wikipedia editor.


-If this is going to turn into the grand feature comparision table, 
everyone might as well be thinking from day one that inevitably there will 
be columns for Oracle (with a volunteer to fill out already), SQL Server, 
DB2, etc. and plan a useful way to manage all that data from the 
beginning.  That's another reason why the Wiki is a bad way to cope with 
this data; adding another column is a painful and error-prone operation.


--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Joshua D. Drake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tony Caduto wrote:
> Dave Page wrote:
>> Couple of corrections Tony:
>>
>> - You don't necessarily need to stop the postmaster to take a filesystem
>> backup -
>> http://www.postgresql.org/docs/8.2/interactive/continuous-archiving.html#BACKUP-BASE-BACKUP.

>>
>>   
> 
> Thanks  Dave.
> Will update ASAP.
> 
> I agree with you on the multi-threaded.  I think I will add a note
> saying the the multi-threaded architecture is only advantageous  on
> Windows.

And Solaris.

Joshua D. Drake

> I have seen instances where the threaded version of Firebird completely
> craps out because one of the threads  has issues.
> 
> Will also make a note that it can run on FAT32 with some limitations.
> 
> Later,
> 
> Tony
> 
> 
> 
> ---(end of broadcast)---
> TIP 1: if posting/reading through Usenet, please send an appropriate
>   subscribe-nomail command to [EMAIL PROTECTED] so that your
>   message can get through to the mailing list cleanly
> 


- --

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGzdyOATb/zqfZUUQRAjYtAJ9GxNvF46JXM34i6Kf0RE7TLwkGggCeN5QD
eELS+fyixPqlB/dYiGkC/vM=
=wN+j
-END PGP SIGNATURE-

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Joshua D. Drake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lewis Cunningham wrote:
> If anyone is interested, I could answer the questions for Oracle and
> you could add those, too.  Be interesting to see a chart like that
> (that stays updated after releases) for a large assortment of
> databases.
> 
> If we add a bunch of different databases, it might be easier to
> manipulate if it was stored in a database.  MS-Access maybe?  ;-)

Let's get this up on the wiki.

Joshua D. Drake

> 
> LewisC
> 
> --- Tony Caduto <[EMAIL PROTECTED]> wrote:
> 
>> Check it out here:
>>
>> http://www.amsoftwaredesign.com/pg_vs_fb
>>
>>
>> When comparing in the grid the only major advantage FB has is
>> probably 
>> BLOB support.
>> PG only suppports 1 gb while FB supports 32gb.  Bytea is pretty
>> slow as 
>> well when compared to the FB BLOB support.
>>
>> The other area is Character sets and collation.  They support it at
>> a 
>> field level as well as the database.
>>
>> Other than that I would say PG kicks butt.
>>
>> If there is any interest I could also add MySQL 5.0 to the mix as
>> the 
>> third column.
>>
>>
>> Later,
>>
>> Tony
>>
>> ---(end of
>> broadcast)---
>> TIP 1: if posting/reading through Usenet, please send an
>> appropriate
>>subscribe-nomail command to [EMAIL PROTECTED] so that
>> your
>>message can get through to the mailing list cleanly
>>
> 
> 
> ---
> Lewis R Cunningham
> 
> An Expert's Guide to Oracle Technology
> http://blogs.ittoolbox.com/oracle/guide/
> 
> LewisC's Random Thoughts
> http://lewiscsrandomthoughts.blogspot.com/
> 
> EnterpriseDB: The Definitive Reference
> http://tinyurl.com/39246e
> --
> 
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match
> 


- --

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGzdNoATb/zqfZUUQRAh/sAJ92Ko3lB6eCGSyJJyoPw5sn4VI44QCdGTjc
XzyzrDQKnA7mgoNXDohvUpY=
=Um04
-END PGP SIGNATURE-

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Lewis Cunningham]

If anyone is interested, I could answer the questions for Oracle and
you could add those, too.  Be interesting to see a chart like that
(that stays updated after releases) for a large assortment of
databases.

If we add a bunch of different databases, it might be easier to
manipulate if it was stored in a database.  MS-Access maybe?  ;-)

LewisC

--- Tony Caduto <[EMAIL PROTECTED]> wrote:

> Check it out here:
> 
> http://www.amsoftwaredesign.com/pg_vs_fb
> 
> 
> When comparing in the grid the only major advantage FB has is
> probably 
> BLOB support.
> PG only suppports 1 gb while FB supports 32gb.  Bytea is pretty
> slow as 
> well when compared to the FB BLOB support.
> 
> The other area is Character sets and collation.  They support it at
> a 
> field level as well as the database.
> 
> Other than that I would say PG kicks butt.
> 
> If there is any interest I could also add MySQL 5.0 to the mix as
> the 
> third column.
> 
> 
> Later,
> 
> Tony
> 
> ---(end of
> broadcast)---
> TIP 1: if posting/reading through Usenet, please send an
> appropriate
>subscribe-nomail command to [EMAIL PROTECTED] so that
> your
>message can get through to the mailing list cleanly
> 


---
Lewis R Cunningham

An Expert's Guide to Oracle Technology
http://blogs.ittoolbox.com/oracle/guide/

LewisC's Random Thoughts
http://lewiscsrandomthoughts.blogspot.com/

EnterpriseDB: The Definitive Reference
http://tinyurl.com/39246e
--

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Scott Marlowe]

On 8/23/07, Tony Caduto <[EMAIL PROTECTED]> wrote:
> Check it out here:
>
> http://www.amsoftwaredesign.com/pg_vs_fb
> If there is any interest I could also add MySQL 5.0 to the mix as the
> third column.

If you do, you should really do it as MySQL-isam and MySQL-innodb.

the limitations of each table handler are often as much different as
to make it another database server.  i.e. no full text search on
innodb tables, no foreign keys on isam tables, etc...

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Richard Broersma Jr]

--- Tony Caduto <[EMAIL PROTECTED]> wrote:

> Check it out here:
> 
> http://www.amsoftwaredesign.com/pg_vs_fb

One row that you could elaborate on is:
CHECK CONSTRAINTS support for correlated sub-queries.
PostgreSQL doesn't official support this kink of constraint unless it is rolled 
up in a function. 
I am not sure what support FB has for this.

Another Constraint row you could add would be:
CREATE ASSERTION  which is a schema level constraint.  Currently PostgreSQL 
doesn't support this,
I am not sure if FB does either.

Also you could mention PostgreSQL support for row-wise comparison:
i.e. WHERE ( last_name, city, gender ) = ( 'Doe', 'Paris', 'female' );

and PostgreSQL support for additional SQL comparison operators:
i.e. WHERE (( last_name, city, gender ) = ( 'Doe', 'Paris', 'female' )) IS 
UNKNOWN;
-- return all people who might meet this criteria if their null field where 
known.

Regards,
Richard Broersma Jr.


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Joshua D. Drake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tony Caduto wrote:
> Dave Page wrote:
>> Tony Caduto wrote:
>>  
>>> Other than that I would say PG kicks butt.
>>> 
>>
>> You're just realising that? :-)
>>
>>   
> 
> Ah, I new that around 2004 :-)  I just have to convince Delphi users of
> that :-)

My understanding is the Firebird is relatively non-configured though
isn't it? For a large scale client server app there is no question that
PG is going to wipe the universe with Firebird, but I would think that
Firebird may be better suited for embedded shipping that kind of thing.

Sincerely,

Joshua D. Drake

> 
> 
> Later,
> 
> Tony
> 
> ---(end of broadcast)---
> TIP 4: Have you searched our list archives?
> 
>   http://archives.postgresql.org/
> 


- --

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGzb0ZATb/zqfZUUQRAttRAJ4mamXurjzMDH9kqD3cWt9EC6RT7wCfRpkE
efUsuyz2f1GQKSs4dfgzr+A=
=JHrY
-END PGP SIGNATURE-

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Tony Caduto]

Dave Page wrote:

Tony Caduto wrote:
  

Other than that I would say PG kicks butt.



You're just realising that? :-)

  


Ah, I new that around 2004 :-)  I just have to convince Delphi users of 
that :-)



Later,

Tony

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org/

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Tony Caduto]

Dave Page wrote:

Couple of corrections Tony:

- You don't necessarily need to stop the postmaster to take a filesystem
backup -
http://www.postgresql.org/docs/8.2/interactive/continuous-archiving.html#BACKUP-BASE-BACKUP.
Obviously that assumes logs will be replayed during recovery.

- The native win32 port will run on FAT32, we just prevent the installer
from initdb'ing on such a partition. You can do it manually however, but
tablespaces won't work.

I'm a little puzzled about why you list multi-threaded architecture as a
feature - on Windows it's a little more efficient of course, but the
multi-process architecture is arguably far more robust, and certainly
used to be more portable (I'm not sure that's still the case for
platforms we actually care about).

Regards, Dave.


  


Thanks  Dave.
Will update ASAP.

I agree with you on the multi-threaded.  I think I will add a note 
saying the the multi-threaded architecture is only advantageous  on Windows.
I have seen instances where the threaded version of Firebird completely 
craps out because one of the threads  has issues.


Will also make a note that it can run on FAT32 with some limitations.

Later,

Tony



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Erik Jones]

On Aug 23, 2007, at 12:00 AM, Tony Caduto wrote:


Check it out here:

http://www.amsoftwaredesign.com/pg_vs_fb


When comparing in the grid the only major advantage FB has is  
probably BLOB support.
PG only suppports 1 gb while FB supports 32gb.  Bytea is pretty  
slow as well when compared to the FB BLOB support.


Actually, Postgres's large object facility allows storage of binary  
data up to 2GB in size.  http://www.postgresql.org/docs/8.2/ 
interactive/largeobjects.html


Erik Jones

Software Developer | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dave Page]

Tony Caduto wrote:
> Check it out here:
> 
> http://www.amsoftwaredesign.com/pg_vs_fb

Couple of corrections Tony:

- You don't necessarily need to stop the postmaster to take a filesystem
backup -
http://www.postgresql.org/docs/8.2/interactive/continuous-archiving.html#BACKUP-BASE-BACKUP.
Obviously that assumes logs will be replayed during recovery.

- The native win32 port will run on FAT32, we just prevent the installer
from initdb'ing on such a partition. You can do it manually however, but
tablespaces won't work.

I'm a little puzzled about why you list multi-threaded architecture as a
feature - on Windows it's a little more efficient of course, but the
multi-process architecture is arguably far more robust, and certainly
used to be more portable (I'm not sure that's still the case for
platforms we actually care about).

Regards, Dave.

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] PostgreSQL vs Firebird feature comparison finished

[Dave Page]

Tony Caduto wrote:
> Other than that I would say PG kicks butt.

You're just realising that? :-)

> If there is any interest I could also add MySQL 5.0 to the mix as the
> third column.

I'd be interested to see that.

Regards, Dave

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

[GENERAL] PostgreSQL vs Firebird feature comparison finished

[Tony Caduto]

Check it out here:

http://www.amsoftwaredesign.com/pg_vs_fb


When comparing in the grid the only major advantage FB has is probably 
BLOB support.
PG only suppports 1 gb while FB supports 32gb.  Bytea is pretty slow as 
well when compared to the FB BLOB support.


The other area is Character sets and collation.  They support it at a 
field level as well as the database.


Other than that I would say PG kicks butt.

If there is any interest I could also add MySQL 5.0 to the mix as the 
third column.



Later,

Tony

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly