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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
23 matches
Mail list logo
