Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Alex Turner]

Quick reply on this - I have worked with Oracle, MSSQL and Postgresql,
the first and last extensively.

Oracle is not that expensive - standard one can be got for $149/user
or $5k/CPU, and for most applications, the features in standard one
are fine.

Oracle is a beast to manage.  It does alot more logging that most
other RDBMses, which is where you start needed more disk partitions
for it to be effective (System, Redo, Archive Redo, Undo, Table
(posibly Index)).  The biggest cost for Oracle is hiring someone who
knows how to set it up and maintain it properly, and it can be quite a
feat.

MS-SQL _is_ expensive for what you get.  MS-SQL lacks many features
that both Postgresql and oracle.  I have particularly noticed
aggregate queries and grouping operations aren't as advanced. 
Transact-SQL is also big pain in the ass.

Neither Oracle nor MS-SQL have the range of stored procedure langauges
that Postgresql supports.  Postgresql is certainly the easiest to set
up and maintain and get good performance.  For small to medium
database sizes on systems with limited drive partitions, I would
expect postgresql to outperform Oracle in most tests.  If you have
$25k to spend on a DB server, and over $100k/year for an Oracle DBA,
and you need 60x60x24x7x365 uptime with recoverability, realtime
replication and clustering - Oracle might be your best bet, otherwise
- pick Postgresql ;)

Alex Turner
NetEconoimst


On Mon, 10 Jan 2005 07:30:12 +, Gary Doades <[EMAIL PROTECTED]> wrote:
> Randolf Richardson wrote:
> >   I'm looking for recent performance statistics on PostgreSQL vs. Oracle
> > vs. Microsoft SQL Server.  Recently someone has been trying to convince my
> > client to switch from SyBASE to Microsoft SQL Server (they originally wanted
> > to go with Oracle but have since fallen in love with Microsoft).  All this
> > time I've been recommending PostgreSQL for cost and stability (my own 
> > testing
> > has shown it to be better at handling abnormal shutdowns and using fewer
> > system resources) in addition to true cross-platform compatibility.
> >
> 
> I'm not sure that you are going to get a simple answer to this one. It
> really depends on what you are trying to do. The only way you will know
> for sure what the performance of PostgreSQL is is to try it with samples
> of your common queries, updates etc.
> 
> I have recently ported a moderately complex database from MS SQLServer
> to Postgres with reasonable success. 70% selects, 20% updates, 10%
> insert/deletes. I had to do a fair bit of work to get the best
> performance out of Postgres, but most of the SQL has as good or better
> performance then SQLServer. There are still areas where SQLServer
> outperforms Postgres. For me these tend to be the larger SQL Statements
> with correlated subqueries. SQLServer tends to optimise them better a
> lot of the time. Updates tend to be a fair bit faster on SQLServer too,
> this may be MS taking advantage of Windows specific optimisations in the
> filesystem.
> 
> I did give Oracle a try out of curiosity. I never considered it
> seriously because of the cost. The majority of my SQL was *slower* under
> Oracle than SQLServer. I spent some time with it and did get good
> performance, but it took a *lot* of work tuning to Oracle specific ways
> of doing things.
> 
> My Summary:
> 
> SQLServer: A good all round database, fast, stable. Moderately expensive
> to buy, cheap and easy to work with and program for (on Windows)
> 
> PostgreSQL: A good all rounder, fast most of the time, stable. Free to
> acquire, more expensive to work with and program for. Client drivers may
> be problematic depending on platform and programming language. Needs
> more work than SQLServer to get the best out of it. Improving all the
> time and worth serious consideration.
> 
> Oracle: A bit of a monstrosity. Can be very fast with a lot of work,
> can't comment on stability but I guess it's pretty good. Very expensive
> to acquire and work with. Well supported server and clients.
> 
> Cheers,
> Gary.
> 
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
>

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Yann Michel]

Hi,

On Mon, Jan 10, 2005 at 11:07:55AM -0500, Alex Turner wrote:
> Neither Oracle nor MS-SQL have the range of stored procedure langauges
> that Postgresql supports.  

That is not true. Oracle uses PL/SQL for its stored procedures and
M$-SQL does have a stored procedural language.


Regards,
Yann - OCA ;-)

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

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Frank Wiles]

On Mon, 10 Jan 2005 18:33:07 +0100
Yann Michel <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> On Mon, Jan 10, 2005 at 11:07:55AM -0500, Alex Turner wrote:
> > Neither Oracle nor MS-SQL have the range of stored procedure
> > langauges that Postgresql supports.  
> 
> That is not true. Oracle uses PL/SQL for its stored procedures and
> M$-SQL does have a stored procedural language.

  By "range" I believe he meant number of stored procedure languages. 
  He wasn't saying they didn't have a stored procedure langauge or
  support, just that PostgreSQL had more languages to choose from. 

 -
   Frank Wiles <[EMAIL PROTECTED]>
   http://www.wiles.org
 -


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

   http://archives.postgresql.org

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Alex Turner]

You sir are correct!  You can't use perl in MS-SQL or Oracle ;).

Alex Turner
NetEconomist


On Mon, 10 Jan 2005 11:42:00 -0600, Frank Wiles <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Jan 2005 18:33:07 +0100
> Yann Michel <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> >
> > On Mon, Jan 10, 2005 at 11:07:55AM -0500, Alex Turner wrote:
> > > Neither Oracle nor MS-SQL have the range of stored procedure
> > > langauges that Postgresql supports.
> >
> > That is not true. Oracle uses PL/SQL for its stored procedures and
> > M$-SQL does have a stored procedural language.
> 
>   By "range" I believe he meant number of stored procedure languages.
>   He wasn't saying they didn't have a stored procedure langauge or
>   support, just that PostgreSQL had more languages to choose from.
> 
>  -
>Frank Wiles <[EMAIL PROTECTED]>
>http://www.wiles.org
>  -
> 
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
> 
>http://archives.postgresql.org
>

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

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Pierre-Frédéric Caillaud]

On Mon, 10 Jan 2005 12:46:01 -0500, Alex Turner <[EMAIL PROTECTED]> wrote:
You sir are correct!  You can't use perl in MS-SQL or Oracle ;).
Can you benefit from the luminous power of Visual Basic as a pl in 
MSSQL ?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Gary Doades]

Pierre-Frédéric Caillaud wrote:
On Mon, 10 Jan 2005 12:46:01 -0500, Alex Turner <[EMAIL PROTECTED]> wrote:
You sir are correct!  You can't use perl in MS-SQL or Oracle ;).

Can you benefit from the luminous power of Visual Basic as a pl in 
MSSQL ?

The .NET Runtime will be a part of the next MS SQLServer engine. You 
will be able to have C# as a pl in the database engine with the next 
version of MSSQL. That certainly will be something to think about.

Cheers,
Gary.

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Pierre-Frédéric Caillaud]

The .NET Runtime will be a part of the next MS SQLServer engine. You  
will be able to have C# as a pl in the database engine with the next  
version of MSSQL. That certainly will be something to think about.
Ah, well, if it's C# (or even VB.NET) then it's serious !
I thought postgres had pl/java ?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Dave Cramer]

Currently there are two java pl's available for postgres.
Dave
Gary Doades wrote:
Pierre-Frédéric Caillaud wrote:
On Mon, 10 Jan 2005 12:46:01 -0500, Alex Turner <[EMAIL PROTECTED]> 
wrote:

You sir are correct!  You can't use perl in MS-SQL or Oracle ;).

Can you benefit from the luminous power of Visual Basic as a pl 
in MSSQL ?

The .NET Runtime will be a part of the next MS SQLServer engine. You 
will be able to have C# as a pl in the database engine with the next 
version of MSSQL. That certainly will be something to think about.

Cheers,
Gary.

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561
---(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

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Rosser Schwarz]

while you weren't looking, Gary Doades wrote:

> The .NET Runtime will be a part of the next MS SQLServer engine.

It won't be long before someone writes a procedural language binding
to PostgreSQL for Parrot [1].  That should offer us a handful or six
more languages that can be used, including BASIC, Ruby and Scheme,
Perl (5 and 6), Python and TCL for more or less free, and ... wait for
it, BrainF***.

IIRC, people have talked about porting C# to Parrot, as well.

/rls

[1] The new VM for Perl 6, &c: http://www.parrotcode.org

-- 
:wq

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

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Gary Doades]

Rosser Schwarz wrote:
while you weren't looking, Gary Doades wrote:

The .NET Runtime will be a part of the next MS SQLServer engine.

It won't be long before someone writes a procedural language binding
to PostgreSQL for Parrot [1].  That should offer us a handful or six
more languages that can be used, including BASIC, Ruby and Scheme,
Perl (5 and 6), Python and TCL for more or less free, and ... wait for
it, BrainF***.
IIRC, people have talked about porting C# to Parrot, as well.
Or perhaps get the mono engine in there somewhere to pick up another 
dozen or so languages supported by .NET and mono..

Cheers,
Gary.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Dave Cramer]

I'm curious, why do you think that's serious ? What do you really expect 
to do in the stored procedure ? Anything of consequence will seriously 
degrade performance if you select it in say a million rows.

Pierre-Frédéric Caillaud wrote:
The .NET Runtime will be a part of the next MS SQLServer engine. You  
will be able to have C# as a pl in the database engine with the next  
version of MSSQL. That certainly will be something to think about.

Ah, well, if it's C# (or even VB.NET) then it's serious !
I thought postgres had pl/java ?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Gary Doades]

Dave Cramer wrote:
I'm curious, why do you think that's serious ? What do you really expect 
to do in the stored procedure ? Anything of consequence will seriously 
degrade performance if you select it in say a million rows.

I'm not sure what you mean by "select it in a million rows". I would 
expect to write a procedure within the database engine to select a 
million rows, process them and return the result to the client. Very 
efficient.

Cheers,
Gary.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Jim C. Nasby]

On Mon, Jan 10, 2005 at 12:46:01PM -0500, Alex Turner wrote:
> You sir are correct!  You can't use perl in MS-SQL or Oracle ;).
 
On the other hand, PL/SQL is incredibly powerful, especially combined
with all the tools/utilities that come with Oracle. I think you'd be
hard-pressed to find too many real-world examples where you could do
something with a PostgreSQL procedural language that you couldn't do
with PL/SQL.
-- 
Jim C. Nasby, Database Consultant   [EMAIL PROTECTED] 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Dave Cramer]

Ok, so one use case is to select a large number of rows and do some 
non-trivial operation on them.
I can see where getting the rows inside the server process ( ie some 
procedural language ) thereby reducing the round trip overhead would be 
beneficial. However how do you deal with the lack of control ? For 
instance what happens if you run out of memory while doing this ? I'm 
not sure about other DB'S but if you crash the procedural language 
inside postgres you will bring the server down.

It would seem to me that any non-trivial operation would be better 
handled outside the server process, even if it costs you the round trip.

Dave

Gary Doades wrote:
Dave Cramer wrote:
I'm curious, why do you think that's serious ? What do you really 
expect to do in the stored procedure ? Anything of consequence will 
seriously degrade performance if you select it in say a million rows.

I'm not sure what you mean by "select it in a million rows". I would 
expect to write a procedure within the database engine to select a 
million rows, process them and return the result to the client. Very 
efficient.

Cheers,
Gary.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Christopher Browne]

Oops! [EMAIL PROTECTED] (Pierre-Frédéric Caillaud) was seen spray-painting on a 
wall:
>> The .NET Runtime will be a part of the next MS SQLServer engine. You
>> will be able to have C# as a pl in the database engine with the next
>> version of MSSQL. That certainly will be something to think about.
>
>   Ah, well, if it's C# (or even VB.NET) then it's serious !
>   I thought postgres had pl/java ?

Someone's working on pl/Mono...

  
-- 
"cbbrowne","@","gmail.com"
http://cbbrowne.com/info/slony.html
"... the open research model is justified. There is a passage in the
Bible (John 8:32, and on a plaque in CIA HQ), "And ye shall know the
truth, and the truth shall set ye free." -- Dave Dittrich 

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

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[PFC]

I'm curious, why do you think that's serious ? What do you really expect
	Simply because I don't like VB non .NET, but C# is a much much better  
language, and even VB.NET is decent.

to do in the stored procedure ? Anything of consequence will seriously  
degrade performance if you select it in say a million rows.
	Well, if such a thing needed to be done, like processing a lot of rows to  
yield a small result set, it certainly should be done inside the server,  
but as another poster said, being really careful about memory usage.

	But, that was not my original idea ; I find that even for small functions  
plsql is a bit ugly compared to the usual suspects like Python and others  
; unfortunately I think there is overhead in converting the native  
postgres datatype to their other language counterparts, which is why I did  
not try them (yet).

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

[PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

[Miles Keaton]

I'm sorry if there's a URL out there answering this, but I couldn't find it.

For those of us that need the best performance possible out of a
dedicated dual-CPU PostgreSQL server, what is recommended?

AMD64/Opteron or i386/Xeon?

Linux or FreeBSD or _?_

I'm assuming hardware RAID 10 on 15k SCSI drives is fastest disk performance.

Any hardware-comparison benchmarks out there showing the results for
different PostgreSQL setups?

Thanks!

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

[Joshua D. Drake]

Miles Keaton wrote:
I'm sorry if there's a URL out there answering this, but I couldn't find it.
For those of us that need the best performance possible out of a
dedicated dual-CPU PostgreSQL server, what is recommended?
AMD64/Opteron or i386/Xeon?
 

AMD64/Opteron
Linux or FreeBSD or _?_
 

This is a religious question :)
I'm assuming hardware RAID 10 on 15k SCSI drives is fastest disk performance.
 

And many, many disks -- yes.
Sincerely,
Joshua D. Drake

Any hardware-comparison benchmarks out there showing the results for
different PostgreSQL setups?
Thanks!
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
 


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;PO Box 215 ;Cascade Locks;OR;97014;US
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
x-mozilla-html:FALSE
url:http://www.commandprompt.com
version:2.1
end:vcard


---(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

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

[Christopher Browne]

Quoth [EMAIL PROTECTED] (Miles Keaton):
> I'm sorry if there's a URL out there answering this, but I couldn't
> find it.
>
> For those of us that need the best performance possible out of a
> dedicated dual-CPU PostgreSQL server, what is recommended?
>
> AMD64/Opteron or i386/Xeon?

Xeon sux pretty bad...

> Linux or FreeBSD or _?_

The killer question won't be of what OS is "faster," but rather of
what OS better supports the fastest hardware you can get your hands
on.  

We tried doing some FreeBSD benchmarking on a quad-Opteron box, only
to discover that the fibrechannel controller worked in what amounted
to a "PAE-like" mode where it only talked DMA in a 32 bit manner.  We
might have found a more suitable controller, given time that was not
available.

A while back I tried to do some FreeBSD benchmarking on a quad-Xeon
box with 8GB of RAM.  I couldn't find _any_ RAID controller compatible
with that configuration, so FreeBSD wasn't usable on that hardware
unless I told the box to ignore half the RAM.

There lies the rub of the problem: you need to make sure all the vital
components are able to run "full blast" in order to maximize
performance.

The really high end SCSI controllers may only have supported drivers
for some specific set of OSes, and it seems to be pretty easy to put
together boxes where one or another component leaps into the "That
Doesn't Work!" category.

> I'm assuming hardware RAID 10 on 15k SCSI drives is fastest disk
> performance.

RAID controllers tend to use i960 or StrongARM CPUs that run at speeds
that _aren't_ all that impressive.  With software RAID, you can take
advantage of the _enormous_ increases in the speed of the main CPU.

I don't know so much about FreeBSD's handling of this, but on Linux,
there's pretty strong indication that _SOFTWARE_ RAID is faster than
hardware RAID.

It has the further merit that you're not dependent on some disk
formatting scheme that is only compatible with the model of RAID
controller that you've got, where if the controller breaks down, you
likely have to rebuild the whole array from scratch and your data is
toast.

The assumptions change if you're looking at really high end disk
arrays, but that's certainly another story.
-- 
(format nil "[EMAIL PROTECTED]" "cbbrowne" "acm.org")
http://linuxfinances.info/info/finances.html
Real Programmers are surprised when the odometers in their cars don't
turn from 9 to A.

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

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

[Christopher Browne]

Xeon sux pretty bad...

> Linux or FreeBSD or _?_

The killer question won't be of what OS is "faster," but rather of
what OS better supports the fastest hardware you can get your hands
on.  

We tried doing some FreeBSD benchmarking on a quad-Opteron box, only
to discover that the fibrechannel controller worked in what amounted
to a "PAE-like" mode where it only talked DMA in a 32 bit manner.  We
might have found a more suitable controller, given time that was not
available.

A while back I tried to do some FreeBSD benchmarking on a quad-Xeon
box with 8GB of RAM.  I couldn't find _any_ RAID controller compatible
with that configuration, so FreeBSD wasn't usable on that hardware
unless I told the box to ignore half the RAM.

There lies the rub of the problem: you need to make sure all the vital
components are able to run "full blast" in order to maximize
performance.

The really high end SCSI controllers may only have supported drivers
for some specific set of OSes, and it seems to be pretty easy to put
together boxes where one or another component leaps into the "That
Doesn't Work!" category.

> I'm assuming hardware RAID 10 on 15k SCSI drives is fastest disk
> performance.

RAID controllers tend to use i960 or StrongARM CPUs that run at speeds
that _aren't_ all that impressive.  With software RAID, you can take
advantage of the _enormous_ increases in the speed of the main CPU.

I don't know so much about FreeBSD's handling of this, but on Linux,
there's pretty strong indication that _SOFTWARE_ RAID is faster than
hardware RAID.

It has the further merit that you're not dependent on some disk
formatting scheme that is only compatible with the model of RAID
controller that you've got, where if the controller breaks down, you
likely have to rebuild the whole array from scratch and your data is
toast.

The assumptions change if you're looking at really high end disk
arrays, but that's certainly another story.
-- 
(format nil "[EMAIL PROTECTED]" "cbbrowne" "acm.org")
http://linuxfinances.info/info/finances.html
Real Programmers are surprised when the odometers in their cars don't
turn from 9 to A.

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

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

[Joshua D. Drake]

RAID controllers tend to use i960 or StrongARM CPUs that run at speeds
that _aren't_ all that impressive.  With software RAID, you can take
advantage of the _enormous_ increases in the speed of the main CPU.
I don't know so much about FreeBSD's handling of this, but on Linux,
there's pretty strong indication that _SOFTWARE_ RAID is faster than
hardware RAID.
 

Unless something has changed though, you can't run raid 10
with linux software raid and raid 5 sucks for heavy writes.
J

It has the further merit that you're not dependent on some disk
formatting scheme that is only compatible with the model of RAID
controller that you've got, where if the controller breaks down, you
likely have to rebuild the whole array from scratch and your data is
toast.
The assumptions change if you're looking at really high end disk
arrays, but that's certainly another story.
 


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;PO Box 215 ;Cascade Locks;OR;97014;US
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
x-mozilla-html:FALSE
url:http://www.commandprompt.com
version:2.1
end:vcard


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

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

[Josh Berkus]

Chris,

> I don't know so much about FreeBSD's handling of this, but on Linux,
> there's pretty strong indication that _SOFTWARE_ RAID is faster than
> hardware RAID.

Certainly better than an Adaptec.  But not necessarily better than a 
medium-end RAID card, like an LSI.  It really depends on the quality of the 
controller.

Also, expected concurrent activity should influence you.   On  a dedicated 
database server, you'll seldom max out the CPU but will often max of the 
disk, so the CPU required by software RAID is "free".   However, if you have 
a Web/PG/E-mail box which frequently hits 100% CPU, then even a lower-end 
RAID card can be beneficial simply by taking load off the CPU.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

[Gary Doades]

Dave Cramer wrote:
Ok, so one use case is to select a large number of rows and do some 
non-trivial operation on them.
I can see where getting the rows inside the server process ( ie some 
procedural language ) thereby reducing the round trip overhead would be 
beneficial. However how do you deal with the lack of control ? For 
instance what happens if you run out of memory while doing this ? I'm 
not sure about other DB'S but if you crash the procedural language 
inside postgres you will bring the server down.

It would seem to me that any non-trivial operation would be better 
handled outside the server process, even if it costs you the round trip.
Since a .NET language is operating effectively inside a VM it is pretty 
much impossible to bring down the server that way. Only a bug in the 
.NET runtime itself will do that. The C# try/catch/finally with .NET 
global execption last chance handlers will ensure the server and your 
code is well protected.

Cheers,
Gary.
---(end of broadcast)---
TIP 8: explain analyze is your friend