Thread: PostgreSQL vs. Oracle vs. Microsoft
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.
If I can show my client some statistics that PostgreSQL outperforms
these (I'm more concerned about it beating Oracle because I know that
Microsoft's stuff is always slower, but I need the information anyway to
protect my client from falling victim to a 'sales job'), then PostgreSQL will
be the solution of choice as the client has always believed that they need a
high-performance solution.
I've already convinced them on the usual price, cross-platform
compatibility, open source, long history, etc. points, and I've been assured
that if the performance is the same or better than Oracle's and Microsoft's
solutions that PostgreSQL is what they'll choose.
Thanks in advance.
On Thu, 6 Jan 2005 19:01:38 +0000 (UTC) Randolf Richardson <rr@8x.ca> 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. > > If I can show my client some statistics that PostgreSQL > outperforms > these (I'm more concerned about it beating Oracle because I know that > Microsoft's stuff is always slower, but I need the information anyway > to protect my client from falling victim to a 'sales job'), then > PostgreSQL will be the solution of choice as the client has always > believed that they need a high-performance solution. > > I've already convinced them on the usual price, cross-platform > compatibility, open source, long history, etc. points, and I've been > assured that if the performance is the same or better than Oracle's > and Microsoft's solutions that PostgreSQL is what they'll choose. While this doesn't exactly answer your question, I use this little tidbit of information when "selling" people on PostgreSQL. PostgreSQL was chosen over Oracle as the database to handle all of the .org TLDs information. While I don't believe the company that won was chosen solely because they used PostgreSQL vs Oracle ( vs anything else ), it does go to show that PostgreSQL can be used in a large scale environment. Another tidbit you can use in this particular case: I was involved in moving www.ljworld.com, www.lawrence.com, and www.kusports.com from a Sybase backend to a PostgreSQL backend back in 2000-2001. We got roughly a 200% speed improvement at that time and PostgreSQL has only improved since then. I would be more than happy to elaborate on this migration off list if you would like. kusports.com gets a TON of hits especially during "March Madness" and PostgreSQL has never been an issue in the performance of the site. --------------------------------- Frank Wiles <frank@wiles.org> http://www.wiles.org ---------------------------------
Quoting Randolf Richardson <rr@8x.ca>:
> I'm looking for recent performance statistics on PostgreSQL vs. Oracle
>
> vs. Microsoft SQL Server. Recently someone has been trying to convince my
I don't know anything about your customer's requirements other than that they
have a DB currently and somebody(ies) is(are) trying to get them to switch to
another.
I don't think you'll find meaningful numbers unless you do your own benchmarks.
DB performance is very largely determined by how the application functions,
hardware, OS and the DBA's familiarity with the platform. I would suspect that
for any given workload on relatively similar hardware that just about any of the
DB's you mention would perform similarly if tuned appropriately.
> 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.
Right for the customer? How about "Don't fix it if it ain't broke"? Replacing
a DB backend isn't always trivial (understatement). I suppose if their
application is very simple and uses few if any proprietary features of Sybase
then changing the DB would be simple. That depends heavily on the application.
In general, though, you probably shouldn't rip and replace DB platforms unless
there's a very good strategic reason.
I don't know about MSSQL, but I know that, if managed properly, Sybase and
Oracle can be pretty rock-solid and high performing. If *you* have found FooDB
to be the most stable and highest performing, then that probably means that
FooDB is the one you're most familiar with rather than FooDB being the best in
all circumstances. PostgreSQL is great. I love it. In the right hands and
under the right circumstances, it is the best DB. So is Sybase. And Oracle.
And MSSQL.
>
> If I can show my client some statistics that PostgreSQL outperforms
> these (I'm more concerned about it beating Oracle because I know that
> Microsoft's stuff is always slower, but I need the information anyway to
> protect my client from falling victim to a 'sales job'), then PostgreSQL will
>
> be the solution of choice as the client has always believed that they need a
>
> high-performance solution.
>
Unless there's a really compelling reason to switch, optimizing what they
already have is probably the best thing for them. They've already paid for it.
They've already written their own application and have some familiarity with
managing the DB. According to Sybase, Sybase is the fastest thing going. :-)
Which is probably pretty close to the truth if the application and DB are tuned
appropriately.
> I've already convinced them on the usual price, cross-platform
> compatibility, open source, long history, etc. points, and I've been assured
>
> that if the performance is the same or better than Oracle's and Microsoft's
>
> solutions that PostgreSQL is what they'll choose.
Are you telling me that they're willing to pay $40K per CPU for Oracle if it
performs 1% better than PostgreSQL, which is $0? Not to mention throw away
Sybase, which is a highly scalable platform in and of itself.
The best DB platform is what they currently have, regardless of what they have,
unless there is a very compelling reason to switch.
>
> Thanks in advance.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
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.
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 +0000, Gary Doades <gpd@gpdnet.co.uk> 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 >
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 ;-)
On Mon, 10 Jan 2005 18:33:07 +0100 Yann Michel <yann-postgresql@spline.de> 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 <frank@wiles.org> http://www.wiles.org ---------------------------------
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 <frank@wiles.org> wrote: > On Mon, 10 Jan 2005 18:33:07 +0100 > Yann Michel <yann-postgresql@spline.de> 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 <frank@wiles.org> > http://www.wiles.org > --------------------------------- > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
On Mon, 10 Jan 2005 12:46:01 -0500, Alex Turner <armtuk@gmail.com> 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 ?
Pierre-Frédéric Caillaud wrote: > On Mon, 10 Jan 2005 12:46:01 -0500, Alex Turner <armtuk@gmail.com> 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.
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 <armtuk@gmail.com> >> 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 majordomo@postgresql.org > > -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
> 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 ?
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
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.
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
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.
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 decibel@decibel.org 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?"
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
Oops! lists@boutiquenumerique.com (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... <http://gborg.postgresql.org/project/plmono/projdisplay.php> -- "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
> 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).
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.
I understand that but I have seen VM's crash. This does bring up another point. Since postgresql is not threaded a .NET pl would require a separate VM for each connection (unless you can share the vm ?). One of the java pl's (pl-j) for postgres has dealt with this issue. For a hundred connections that's a hundred .NET vm's or java vm's. Is the .NET VM shareable ? Dave Gary Doades wrote: > 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 > > -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
Connect to an external data system using a socket and propagate data changes using a trigger... I've had to do this, and it sucks to be stuck in Oracle! Alex Turner NetEconomist On Mon, 10 Jan 2005 17:29:52 -0600, Jim C. Nasby <decibel@decibel.org> wrote: > 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 decibel@decibel.org > 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 majordomo@postgresql.org >
Jim wrote: 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.
Rick mumbled: You can't get it for nothing! %)
"Jim C. Nasby"
<decibel@decibel.org> To: alex@neteconomist.com
Sent by: cc: Frank Wiles <frank@wiles.org>, Yann Michel
<yann-postgresql@spline.de>,
pgsql-performance-owner@pos gpd@gpdnet.co.uk, pgsql-performance@postgresql.org
tgresql.org Subject: Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft
01/10/2005 06:29 PM
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 decibel@decibel.org
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 majordomo@postgresql.org
Dave Cramer wrote: > I understand that but I have seen VM's crash. > > This does bring up another point. Since postgresql is not threaded a > .NET pl would require a separate VM for each connection (unless you can > share the vm ?). One of the java pl's (pl-j) for postgres has dealt > with this issue. > For a hundred connections that's a hundred .NET vm's or java vm's. > > Is the .NET VM shareable ? > In Windows, most certainly. Not sure about mono. Cheers, Gary.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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. Don't forget your support contract cost, as well as licenses for each of your servers: development, testing, QA, etc. Is it really as "cheap" as 5K? I've heard that for any fairly modern system, it's much more, but that may be wrong. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200501122029 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFB5c8gvJuQZxSWSsgRAhRzAKDeWZ9LE2etLspiAiFCG8OeeEGoHwCgoLhb crxreFQ2LNVjAp24beDMK5g= =C59m -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: > Don't forget your support contract cost, as well as licenses for each > of your servers: development, testing, QA, etc. > > Is it really as "cheap" as 5K? I've heard that for any fairly modern > system, it's much more, but that may be wrong. > Sort of -- see: http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=15105 "It is available on single server systems supporting up to a maximum of 2 CPUs" Also note that most industrial strength features (like table partitioning, RAC, OLAP, Enterprise Manager plugins, etc, etc) are high priced options (mostly $10K to $20K per CPU) and they can only be used with the Enterprise edition (which is $40K/CPU *not* $2.5K/CPU). http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103 And you are correct, they expect to be paid for each dev, test, and QA machine too. The $5K edition is just there to get you hooked ;-) By the time you add up what you really want/need, figure you'll spend a couple of orders of magnatude higher, and then > 20% per year for ongoing maintenance/upgrades/support. Joe
This is somewhat correct, and somewhat unfair - bear in mind that Postgresql doesn't have the equivalent features of Oracle enterprise edition including RAC and Enterprise Manager. You can use Oracle Personal edition for development, or pay a per head cost of $149/user for your dev group for standard one, which if you have a small team isn't really that much. If you want commercial support for Postgresql, you must also pay for that too. It's $5k/CPU for standard one edition, so $10k for a dual CPU box. Upgrades are free - once you have an Oracle license it is pretty much good for any version on your platform with your number of CPUs. I'm not advocating that people switch to Oracle at all, It's still much more expensive than Postgresql, and for most small and medium applications Postgresql is much easier to manage and maintain. I would just like to make sure people get their facts straight. I worked for a company that selected MS SQL Server because it was 'cheaper' than Oracle, when infact with the correct Oracle pricing, Oracle was cheaper, and had superior features. I would have prefered that they use Postgresql, which for the project in question would have been more appropriate and cost much less in hardware and software requirements, but they had to have 'Industry Standard'. Oracle ended up costing <$10k with licenses at $149 ea for 25 users, and the support contract wasn't that much of a bear - I can't remember exactly how much, I think it was around $1800/yr. Alex Turner NetEconomist -- Remember, what most consider 'convential wisdom' is neither wise nor the convention. Don't speculate, educate. On Wed, 12 Jan 2005 22:51:24 -0800, Joe Conway <mail@joeconway.com> wrote: > Greg Sabino Mullane wrote: > > Don't forget your support contract cost, as well as licenses for each > > of your servers: development, testing, QA, etc. > > > > Is it really as "cheap" as 5K? I've heard that for any fairly modern > > system, it's much more, but that may be wrong. > > > > Sort of -- see: > http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=15105 > "It is available on single server systems supporting up to a maximum > of 2 CPUs" > > Also note that most industrial strength features (like table > partitioning, RAC, OLAP, Enterprise Manager plugins, etc, etc) are high > priced options (mostly $10K to $20K per CPU) and they can only be used > with the Enterprise edition (which is $40K/CPU *not* $2.5K/CPU). > http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103 > > And you are correct, they expect to be paid for each dev, test, and QA > machine too. > > The $5K edition is just there to get you hooked ;-) By the time you add > up what you really want/need, figure you'll spend a couple of orders of > magnatude higher, and then > 20% per year for ongoing > maintenance/upgrades/support. > > Joe > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
Alex Turner wrote: > I'm not advocating that people switch to Oracle at all, It's still > much more expensive than Postgresql, and for most small and medium > applications Postgresql is much easier to manage and maintain. I > would just like to make sure people get their facts straight. I > worked for a company that selected MS SQL Server because it was > 'cheaper' than Oracle, when infact with the correct Oracle pricing, > Oracle was cheaper, and had superior features. I would have prefered > that they use Postgresql, which for the project in question would have > been more appropriate and cost much less in hardware and software > requirements, but they had to have 'Industry Standard'. Oracle ended > up costing <$10k with licenses at $149 ea for 25 users, and the > support contract wasn't that much of a bear - I can't remember exactly > how much, I think it was around $1800/yr. My facts were straight, and they come from firsthand experience. The point is, it is easy to get trapped into thinking to yourself, "great, I can get a dual CPU oracle server for ~$10K, that's not too bad...". But then later you figure out you really need table partitioning or RAC, and suddenly you have to jump directly to multiple 6 figures. The entry level Oracle pricing is mainly a marketing gimmick -- it is intended to get you hooked. Also note that the per named user license scheme is subject to per CPU minimums that guarantee you'll never spend less than half the per CPU price. Oracle's licensing is so complex that there are businesses out there that subsist solely on helping companies figure it out to save money, and they take a cut of the savings. Oracle's own account reps had a hard time answering this question -- does a hyperthreaded Intel CPU count as 1 or 2 CPUs from a licensing standpoint? We were eventually told 1, but that the decision was "subject to change in the future". Joe
Alex Turner wrote: > I appreciate your information, but it's not valid. Most people don't > need RAC or table partitioning. From a small company perspective, maybe, but not in the least invalid for larger companies. > Many of the features in Oracle EE are just not available in Postgresql at all, and many aren't available in > any version of SQL Server (table partitioning, bitmap indexes and > others). I never claimed otherwise. I said the low end product gets you hooked. Once you're hooked, you'll start to wish for all the wiz-bang features -- after all, that's why you picked Oracle in the first place. > Just because Oracle reps are a little clueless > sometimes doesn't mean that the product pricing sucks. > The minimum user requirement for standard one is 5 users. 5*149=$745, > much less than half the price of a dual or single CPU config. And what happens once you need a quad server? > I'm sorry that you had a bad experience with Oracle, but Oracle is a > fine product, that is available for not alot of $$ if you are willing > to use a bit of elbow grease to learn how it works and don't need > enterprise features, which many other database product simply don't > have, or work very poorly. I never said I had a "bad experience" with Oracle. I pointed out the gotchas. We have several large Oracle boxes running, several MSSQL, and several Postgres -- they all have their strengths and weaknesses. Nuff said -- this thread is way off topic now... Joe
Joe, I appreciate your information, but it's not valid. Most people don't need RAC or table partitioning. Many of the features in Oracle EE are just not available in Postgresql at all, and many aren't available in any version of SQL Server (table partitioning, bitmap indexes and others). If you want all the wiz-bang features, you have to pay the wiz-bang price. Just because Oracle reps are a little clueless sometimes doesn't mean that the product pricing sucks. The minimum user requirement for standard one is 5 users. 5*149=$745, much less than half the price of a dual or single CPU config. I'm sorry that you had a bad experience with Oracle, but Oracle is a fine product, that is available for not alot of $$ if you are willing to use a bit of elbow grease to learn how it works and don't need enterprise features, which many other database product simply don't have, or work very poorly. Alex Turner NetEconomist On Thu, 13 Jan 2005 06:56:52 -0800, Joe Conway <mail@joeconway.com> wrote: > Alex Turner wrote: > > I'm not advocating that people switch to Oracle at all, It's still > > much more expensive than Postgresql, and for most small and medium > > applications Postgresql is much easier to manage and maintain. I > > would just like to make sure people get their facts straight. I > > worked for a company that selected MS SQL Server because it was > > 'cheaper' than Oracle, when infact with the correct Oracle pricing, > > Oracle was cheaper, and had superior features. I would have prefered > > that they use Postgresql, which for the project in question would have > > been more appropriate and cost much less in hardware and software > > requirements, but they had to have 'Industry Standard'. Oracle ended > > up costing <$10k with licenses at $149 ea for 25 users, and the > > support contract wasn't that much of a bear - I can't remember exactly > > how much, I think it was around $1800/yr. > > My facts were straight, and they come from firsthand experience. The > point is, it is easy to get trapped into thinking to yourself, "great, I > can get a dual CPU oracle server for ~$10K, that's not too bad...". But > then later you figure out you really need table partitioning or RAC, and > suddenly you have to jump directly to multiple 6 figures. The entry > level Oracle pricing is mainly a marketing gimmick -- it is intended to > get you hooked. > > Also note that the per named user license scheme is subject to per CPU > minimums that guarantee you'll never spend less than half the per CPU > price. Oracle's licensing is so complex that there are businesses out > there that subsist solely on helping companies figure it out to save > money, and they take a cut of the savings. Oracle's own account reps had > a hard time answering this question -- does a hyperthreaded Intel CPU > count as 1 or 2 CPUs from a licensing standpoint? We were eventually > told 1, but that the decision was "subject to change in the future". > > Joe > >
Randolf Richardson wrote: >> While this doesn't exactly answer your question, I use this little >> tidbit of information when "selling" people on PostgreSQL. PostgreSQL >> was chosen over Oracle as the database to handle all of the .org TLDs >> information. ... > > Do you have a link for that information? I've told a few people about > this and one PostgreSQL advocate (thanks to me -- they were going to be a > Microsoft shop before that) is asking. Of course you could read their application when they were competing with a bunch of other companies using databases from different vendors. I believe this is the link to their response to the database questions... http://www.icann.org/tlds/org/questions-to-applicants-13.htm#Response13TheInternetSocietyISOC
I sometimes also think it's fun to point out that Postgresql bigger companies supporting it's software - like this one: http://www.fastware.com.au/docs/FujitsuSupportedPostgreSQLWhitePaper.pdf with $43 billion revenue -- instead of those little companies like Mysql AB or Oracle. :)
"frank@wiles.org (Frank Wiles)" wrote in pgsql.performance:
> On Thu, 6 Jan 2005 19:01:38 +0000 (UTC)
> Randolf Richardson <rr@8x.ca> 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.
>>
>> If I can show my client some statistics that PostgreSQL
>> outperforms
>> these (I'm more concerned about it beating Oracle because I know that
>> Microsoft's stuff is always slower, but I need the information anyway
>> to protect my client from falling victim to a 'sales job'), then
>> PostgreSQL will be the solution of choice as the client has always
>> believed that they need a high-performance solution.
>>
>> I've already convinced them on the usual price, cross-platform
>> compatibility, open source, long history, etc. points, and I've been
>> assured that if the performance is the same or better than Oracle's
>> and Microsoft's solutions that PostgreSQL is what they'll choose.
>
> While this doesn't exactly answer your question, I use this little
> tidbit of information when "selling" people on PostgreSQL. PostgreSQL
> was chosen over Oracle as the database to handle all of the .org TLDs
> information. While I don't believe the company that won was chosen
> solely because they used PostgreSQL vs Oracle ( vs anything else ),
> it does go to show that PostgreSQL can be used in a large scale
> environment.
Do you have a link for that information? I've told a few people about
this and one PostgreSQL advocate (thanks to me -- they were going to be a
Microsoft shop before that) is asking.
> Another tidbit you can use in this particular case: I was involved
> in moving www.ljworld.com, www.lawrence.com, and www.kusports.com from
> a Sybase backend to a PostgreSQL backend back in 2000-2001. We got
> roughly a 200% speed improvement at that time and PostgreSQL has only
> improved since then. I would be more than happy to elaborate on this
> migration off list if you would like. kusports.com gets a TON of
> hits especially during "March Madness" and PostgreSQL has never been
> an issue in the performance of the site.
SyBase is better suited to the small projects in my opinion. I have a
number of customers in the legal industry who have to use it because the
products they use have a proprietary requirement for it. Fortunately it's
quite stable, and uses very little in the way of system resources, but
there is a license fee -- I'm not complaining at all, it has always been
working well for my clients.
"mudfoot@rawbw.com" wrote in pgsql.performance:
> Quoting Randolf Richardson <rr@8x.ca>:
>
>> I'm looking for recent performance statistics on PostgreSQL
>> vs. Oracle
>>
>> vs. Microsoft SQL Server. Recently someone has been trying to convince
>> my
>
> I don't know anything about your customer's requirements other than that
> they have a DB currently and somebody(ies) is(are) trying to get them to
> switch to another.
>
> I don't think you'll find meaningful numbers unless you do your own
> benchmarks.
>
> DB performance is very largely determined by how the application
> functions,
> hardware, OS and the DBA's familiarity with the platform. I would
> suspect that for any given workload on relatively similar hardware that
> just about any of the DB's you mention would perform similarly if tuned
> appropriately.
>
>> 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.
>
> Right for the customer? How about "Don't fix it if it ain't broke"?
> Replacing a DB backend isn't always trivial (understatement). I suppose
> if their application is very simple and uses few if any proprietary
> features of Sybase then changing the DB would be simple. That depends
> heavily on the application. In general, though, you probably shouldn't
> rip and replace DB platforms unless there's a very good strategic
> reason.
>
> I don't know about MSSQL, but I know that, if managed properly, Sybase
> and Oracle can be pretty rock-solid and high performing. If *you* have
> found FooDB to be the most stable and highest performing, then that
> probably means that FooDB is the one you're most familiar with rather
> than FooDB being the best in all circumstances. PostgreSQL is great. I
> love it. In the right hands and under the right circumstances, it is
> the best DB. So is Sybase. And Oracle. And MSSQL.
That's an objective answer. Unfortunately the issue I'm stuck with is
a Microsoft-crazy sales droid who's arguing that "MS-SQL is so easy to
manage, like all Microsoft products, that a novice can make it outperform
other high-end systems like Oracle even when tuned by an expert." This
crap makes me want to throw up, but in order to keep the client I'm doing
my best to hold it down (I bet many of you are shaking your heads).
The client is leaning away from the sales droid, however, and this is
partly due to the help I've recieved here in these newsgroups -- thanks
everyone.
>> If I can show my client some statistics that PostgreSQL
>> outperforms
>> these (I'm more concerned about it beating Oracle because I know that
>> Microsoft's stuff is always slower, but I need the information anyway
>> to protect my client from falling victim to a 'sales job'), then
>> PostgreSQL will
>>
>> be the solution of choice as the client has always believed that they
>> need a
>>
>> high-performance solution.
>
> Unless there's a really compelling reason to switch, optimizing what
> they already have is probably the best thing for them. They've already
> paid for it.
> They've already written their own application and have some familiarity
> with
> managing the DB. According to Sybase, Sybase is the fastest thing
> going. :-) Which is probably pretty close to the truth if the
> application and DB are tuned appropriately.
I agree with you completely. However, the client's looking at getting
the application completely re-programmed. The current developer didn't
plan it properly, and has been slapping code together as if it's a bowl of
spaghetti. In short, there are many problems with the existing system, and
I'm talking about proper testing procedures that begin even at the design
stage (before any coding begins).
>> I've already convinced them on the usual price, cross-platform
>> compatibility, open source, long history, etc. points, and I've been
>> assured that if the performance is the same or better than Oracle's and
>> Microsoft's solutions that PostgreSQL is what they'll choose.
>
> Are you telling me that they're willing to pay $40K per CPU for Oracle
> if it performs 1% better than PostgreSQL, which is $0? Not to mention
> throw away Sybase, which is a highly scalable platform in and of itself.
>
> The best DB platform is what they currently have, regardless of what
> they have, unless there is a very compelling reason to switch.
[sNip]
Have you heard the saying "Nobody ever got fired for picking IBM?" It
is one of those situations where if they don't spend the money in their
budget, then they lose it the next time around (no suggestions are needed
on this issue, but thanks anyway).
"Ron Mayer <rm_pg@cheapcomplexdevices.com>" wrote in pgsql.performance: > Randolf Richardson wrote: > >>> While this doesn't exactly answer your question, I use this little >>> tidbit of information when "selling" people on PostgreSQL. >>> PostgreSQL was chosen over Oracle as the database to handle all of >>> the .org TLDs information. ... >> >> Do you have a link for that information? I've told a few >> people about >> this and one PostgreSQL advocate (thanks to me -- they were going to be >> a Microsoft shop before that) is asking. > > Of course you could read their application when they were competing > with a bunch of other companies using databases from different vendors. > > I believe this is the link to their response to the database > questions... > > http://www.icann.org/tlds/org/questions-to-applicants-13.htm#Response13Th > eInternetSocietyISOC That's perfect. Thanks!
Randolf Richardson <rr@8x.ca> writes: > "Ron Mayer <rm_pg@cheapcomplexdevices.com>" wrote in pgsql.performance: >> Randolf Richardson wrote: >>> While this doesn't exactly answer your question, I use this little >>> tidbit of information when "selling" people on PostgreSQL. >>> PostgreSQL was chosen over Oracle as the database to handle all of >>> the .org TLDs information. ... > > Do you have a link for that information? >> >> http://www.icann.org/tlds/org/questions-to-applicants-13.htm#Response13TheInternetSocietyISOC > That's perfect. Thanks! This is rather old news, actually, as Afilias (the outfit actually running the registry for ISOC) has been running the .info TLD on Postgres since 2001. They have the contract for the new .mobi TLD. And they are currently one of not many bidders to take over the .net registry when Verisign's contract expires this June. Now *that* will be a hard TLD to ignore ;-) I am actually sitting in a Toronto hotel room right now because I'm attending a meeting sponsored by Afilias for the purpose of initial design of the Slony-II replication system for Postgres (see Slony-I). According to the Afilias guys I've been having dinners with, they got absolutely zero flak about their use of Postgres in connection with the .mobi bid, after having endured very substantial bombardment (cf above link) --- and a concerted disinformation campaign by Oracle --- in connection with the .org and .info bids. As far as the ICANN community is concerned, this is established technology. regards, tom lane
Randolf, You probably won't want to hear this, but this decision likely has nothing to do with brands, models, performance or applications. You are up against a pro salesman who is likely very good at what he does. Instead spewing all sorts of "facts" and statistics to your client, the salesman is probably trying to figure out what is driving your client. Do you know what is driving your client? Why does he want to switch? Why now? Why not next quarter? Why not last quarter? Why does he want to do the application at all? Forget the expected answers, e.g., "We need this application to enhance our competitiveness in the marketplace and increase the blah blah blah." Why does YOUR CLIENT actually care about any of this? Is he trying to impress his boss? Build his career? Demonstrate that he can manage a significant project? Is he trying to get rid of old code from an ex-coworker that he hated? Is it spite? Pride? Is he angling for a bigger budget next year? Is there someone who will be assigned to this project that your client wants to lord over? The list goes on and on, and there is no way that your client is going to admit the truth and say something like, "The real reason I want to do this right now is that my childhood rival at XYZ corp just did a project like this. I need to boost my ego, so I *MUST* do a bigger project, right now." You gotta read between the lines. How important is this and why? How urgent and why? Who all is behind this project? What are each individual's personal motivations? Does anyone resent a leader on the team and secretly wish for this project to fail? Once you know what is actually going on in people's heads, you can begin to build rapport and influence them. You can establish your own credibility and safety with your solution, while planting seeds of doubt about another solution. At its core, this decision is (very likely) not at all about RDBMS performance or anything else related to computing. Have you asked yourself why you care about one solution over another? What's driving you to push Pg over MS? Why? You might want to start answering those questions before you even talk to your client. Good Luck, Marty 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. > > If I can show my client some statistics that PostgreSQL outperforms > these (I'm more concerned about it beating Oracle because I know that > Microsoft's stuff is always slower, but I need the information anyway to > protect my client from falling victim to a 'sales job'), then PostgreSQL > will > be the solution of choice as the client has always believed that they > need a > high-performance solution. > > I've already convinced them on the usual price, cross-platform > compatibility, open source, long history, etc. points, and I've been > assured > that if the performance is the same or better than Oracle's and Microsoft's > solutions that PostgreSQL is what they'll choose. > > Thanks in advance. > >
Randolf Richardson wrote: > > The best DB platform is what they currently have, regardless of what > > they have, unless there is a very compelling reason to switch. > [sNip] > > Have you heard the saying "Nobody ever got fired for picking IBM?" It > is one of those situations where if they don't spend the money in their > budget, then they lose it the next time around (no suggestions are needed > on this issue, but thanks anyway). If that's their situation, then they're almost certainly better off throwing the additional money at beefier hardware than at a more expensive database engine, because the amount of incremental performance they'll get is almost certainly going to be greater with better hardware than with a different database engine. In particular, they're probably best off throwing the money at the highest performance disk subsystem they can afford. But that, like anything else, depends on what they're going to be doing. If it's likely to be a small database with lots of processor-intensive analysis, then a beefier CPU setup would be in order. But in my (limited) experience, the disk subsystem is likely to be a bottleneck long before the CPU is in the general case, especially these days as disk subsystems haven't improved in performance nearly as quickly as CPUs have. -- Kevin Brown kevin@sysexperts.com
"Ron Mayer <rm_pg@cheapcomplexdevices.com>" wrote in pgsql.performance: > I sometimes also think it's fun to point out that Postgresql > bigger companies supporting it's software - like this one: > > http://www.fastware.com.au/docs/FujitsuSupportedPostgreSQLWhitePaper.pdf > > with $43 billion revenue -- instead of those little companies > like Mysql AB or Oracle. > > :) Heheh. That is a good point indeed. When the illogical "everyone else is doing it" argument comes along (as typically does whenever someone is pushing for a Microsoft solution), then this will be very helpful.
"tgl@sss.pgh.pa.us (Tom Lane)" wrote in pgsql.performance: > Randolf Richardson <rr@8x.ca> writes: >> "Ron Mayer <rm_pg@cheapcomplexdevices.com>" wrote in pgsql.performance: >>> Randolf Richardson wrote: >>> >>>> While this doesn't exactly answer your question, I use this little >>>> tidbit of information when "selling" people on PostgreSQL. >>>> PostgreSQL was chosen over Oracle as the database to handle all of >>>> the .org TLDs information. ... >> >> Do you have a link for that information? >> >>> http://www.icann.org/tlds/org/questions-to-applicants-13.htm#Response13 >>> TheInternetSocietyISOC >> >> That's perfect. Thanks! > > This is rather old news, actually, as Afilias (the outfit actually > running the registry for ISOC) has been running the .info TLD on > Postgres since 2001. They have the contract for the new .mobi TLD. Perhaps it's old, but it's new to me because I don't follow that area of the internet very closely. > And they are currently one of not many bidders to take over the .net > registry when Verisign's contract expires this June. Now *that* will > be a hard TLD to ignore ;-) Yes, indeed, that will be. My feeling is that Network Solutions actually manages the .NET and .COM registries far better than anyone else does, and when .ORG was switched away I didn't like the lack of flexibility that I have always enjoyed with .NET and .COM -- the problem is that I have to create a separate account and password for each .ORG internet domain name now and can't just use one master account and password for all of them, and if the same folks are going to be running .NET then I'm going to wind up having more management to do for that one as well (and I'm not talking about just a mere handlful of internet domain names either). > I am actually sitting in a Toronto hotel room right now because I'm > attending a meeting sponsored by Afilias for the purpose of initial > design of the Slony-II replication system for Postgres (see Slony-I). > According to the Afilias guys I've been having dinners with, they > got absolutely zero flak about their use of Postgres in connection > with the .mobi bid, after having endured very substantial bombardment > (cf above link) --- and a concerted disinformation campaign by Oracle > --- in connection with the .org and .info bids. As far as the ICANN > community is concerned, this is established technology. Perhaps you could mention this problem I've noticed to them if you happen to be talking with them. It's obviously not a difficult problem to solve when it comes to good database management and would really make life a lot easier for those of us who are responsible for large numbers of internet domain names.
Randolf Richardson <rr@8x.ca> writes:
> ... the problem is that I have
> to create a separate account and password for each .ORG internet domain
> name now and can't just use one master account and password for all of
> them,
This is a registrar issue; if you don't like the user-interface your
registrar provides, choose another one. It's got nothing to do with
the backend registry, which is merely a database of the publicly visible
(WHOIS) info about your domain.
regards, tom lane
On Fri, Jan 21, 2005 at 04:35:38PM +0000, Randolf Richardson wrote: > Yes, indeed, that will be. My feeling is that Network Solutions > actually manages the .NET and .COM registries far better than anyone else > does, and when .ORG was switched away I didn't like the lack of flexibility > that I have always enjoyed with .NET and .COM -- the problem is that I have > to create a separate account and password for each .ORG internet domain > name now and can't just use one master account and password for all of > them, and if the same folks are going to be running .NET then I'm going to > wind up having more management to do for that one as well (and I'm not > talking about just a mere handlful of internet domain names either). Wildly off-topic, but that's registrar driven, not registry driven. I have a range of domains (.com, .net, .org and others) all accessed from a single login through a single registrar. You need to use a better registrar. As a bit of obPostgresql, though... While the registry for .org is run on Postgresql, the actual DNS is run on Oracle. That choice was driven by the availability of multi-master replication. Like many of the cases where the problem looks like it needs multi-master replication, though, it doesn't really need it. A single master at any one time, but with the ability to dub any of the slaves a new master at any time would be adequate. If that were available for Postgresql I'd choose it over Oracle were I doing a big distributed database backed system again. Cheers, Steve
Centuries ago, Nostradamus foresaw when steve@blighty.com (Steve Atkins) would write: > As a bit of obPostgresql, though... While the registry for .org is > run on Postgresql, the actual DNS is run on Oracle. That choice was > driven by the availability of multi-master replication. > > Like many of the cases where the problem looks like it needs > multi-master replication, though, it doesn't really need it. A > single master at any one time, but with the ability to dub any of > the slaves a new master at any time would be adequate. If that were > available for Postgresql I'd choose it over Oracle were I doing a > big distributed database backed system again. Well, this is something that actually _IS_ available for PostgreSQL in the form of Slony-I. Between "MOVE SET" (that does controlled takeover) and "FAILOVER" (that recovers from the situation where a 'master' node craters), this has indeed become available. Automating activation of the failover process isn't quite there yet, though that's mostly a matter that the methodology would involve considerable tuning of recovery scripts to system behaviour. -- select 'cbbrowne' || '@' || 'ntlug.org'; http://cbbrowne.com/info/slony.html Pay no attention to the PDP-11 behind the front panel. -- PGS, in reference to OZ
On Fri, Jan 21, 2005 at 02:00:03AM -0500, Tom Lane wrote:
> got absolutely zero flak about their use of Postgres in connection
> with the .mobi bid, after having endured very substantial bombardment
Well, "absolutely zero" is probably overstating it, but Tom is right
that PostgreSQL is not the sort of major, gee-it's-strange technology
it once was. PostgreSQL is indeed established technology in the
ICANN world now, and I don't think anyone has an argument that it
can't run a registry without trouble. I certainly believe that
PostgreSQL is a fine technology for this. And it scales just fine;
we added a million domains to .info over a couple days in September,
and the effect on performance was unmeasurable (we'd have added them
faster, but the bottleneck was actually the client). A domain add in
our case is on the order of 10 database write operations; that isn't
a huge load, of course, compared to large real-time manufacturing
data collection or other such applications. (Compared to those kinds
of applications, the entire set of Internet registry systems,
including all the registrars, is not that big.)
Incidentally, someone in this thread was concerned about having to
maintain a separate password for each .org domain. It's true that
that is a registrar, rather than a registry, issue; but it may also
be a case where the back end is getting exposed. The .org registry
uses a new protocol, EPP, to manage objects. One of the features of
EPP is that it gives a kind of password (it's called authInfo) to
each domain. The idea is that the registrant knows this authInfo,
and also the currently-sponsoring registrar. If the registrant wants
to switch to another registrar, s/he can give the authInfo to the new
registrar, who can then use the authInfo in validating a transfer
request. This is intended to prevent the practice (relatively
widespread, alas, under the old protocol) where an unscrupulous party
requests transfers for a (substantial number of) domain(s) without
any authorization. (This very thing has happened recently to a
somewhat famous domain on the Internet. I'll leave it to the gentle
reader to do the required googling. The word "panix" might be of
assistance.) So the additional passwords actually do have a purpose;
but different registrars handle this feature differently. My
suggestion is either to talk to your registrar or change registrars
(or both) to get the behaviour you like. There are hundreds of
registrars for both .info and .org, so finding one which acts the way
you want shouldn't be too tricky.
Anyway, this is pretty far off topic. But in answer to the original
question, Afilias does indeed use PostgreSQL for this, and is happy
to talk on the record about it.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
On Fri, Jan 21, 2005 at 03:23:30PM -0800, Kevin Brown wrote:
> beefier CPU setup would be in order. But in my (limited) experience,
> the disk subsystem is likely to be a bottleneck long before the CPU is
> in the general case, especially these days as disk subsystems haven't
> improved in performance nearly as quickly as CPUs have.
Indeed. And you can go through an awful lot of budget buying solid
state storage ;-)
A
--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin