Mine stops with an error at 2 gigs, believe me. Guess I've got to go jiggle the wires or something. The problem might be SAMBA. Or I have to upgrade from RH 7.2
In 1995, IIRC the biggest hard drive in common use was (quite a bit) less than a gig. It's not surprising the designers decided to use the smaller, more efficient 32 bit addressing. As in all other things related to computers in general (didn't billg once ask why anyone would need more than 640K of RAM, or is that urban myth?), needs change over time.
As hardware develops, the software develops to address it. I remember someone who was shocked that Lotus 123 could create a spreadsheet larger than a (320K 5 1/4" DS) diskette, because how could you save it?
We've come a long way. We'll go a lot further. 64 bit file sizes will seem small and quaint to our childrens' children.
Now, If I could just tar my Linux file system over to my son's spare 60 gig hard drive through SAMBA, I'd have cheap, fast, effective backup. But I have to do it 2 gigs at a time. Grrr... gotta go check up on that BSD stuff.
I've always been amazed that the big database vendors (Microsoft and Oracle for sure, IBM probably) got away with putting restrictions on reviews like this in their EULA's for years, but understood it to be a result of the complexity of configuring the products. That's why we don't see head-to-head comparisons of the major commercial database server products. A couple of small changes to a DB configuration can have a huge effect on the performance of the product, so the companies require their own engineers be on-hand to tune the config. Most publishers just don't have the time or resources required to set up a fair comparison review that fulfills the terms of the EULA. The only comparison reviews we see are published (in ads, mostly) by the vendors themselves. And they never say anything bad about themselves (or anything good about their competition). Sometimes it's the hardware vendors who publish benchmark results, and their purpose is to sell more hardware, not to enlighten end users.
What could possibly cause the same restrictions on anti-virus software? Could it be that difficult to configure? Or is the user above correct in inferring the software must be really bad? I suspect the reason the clause is in the EULA is that some lawyer thought they could get away with it and tried it. Now the court says no, and the vendor makes a pout and removes it. That means the laws work. Yay.
They demonstrated a tripling of the throughput of the machine with those soup-it-up fans! That's impressive. I'll bet that's better than the fan-and-heatsink donor got from his Athlon. It's too bad they couldn't get that "1 Roll eXtreme Duck Tape" to physically support the twin 120 volt fans to really cool off the beast. My experience with these (shredder) devices is that there is another metric besides raw throughput that makes all the difference in perceived "beastliness", and that's the speed of the feeder, analogous to the "first page" speed of a printer, except obviously the opposite. And as long as they have to run 120 VAC to it, they can add all sorts of lights and stuff. (For more 120 VAC computer projects, see etherkillers). Maybe with some tweaking they can hack a truly useful device that attaches to the output bin of a fast printer, and shreds as fast as the pages come out. Then they can haul away the incriminating evidence as fast as it's output.
"...in quite a few cases the new kernel seems to be doing much worse than the old."
Thanks for saying that, I thought I had misread the data. It looks like they're still talking about it, and working on the code tweaks which would optimize performance. The referenced post (and following discussion) seems less than earth-shattering.
I've got to hand it to them, though: they're working hard for a good cause. And the better they do their job, the better it will be for all of the Linux users out here.
Oracle has a much richer set of tools. It ships with DBA Studio, db*Loader, and SQLplus just for starters. PostgreSQL has nothing approaching the power and breadth of the Oracle software that comes with the database, though the psql command line interpreter is a good tool (I hope they've addressed the bug where Ctrl-C to stop scrolling occasionally sends the interpreter into la-la-land).
As far as strictly data engine features go, Oracle has:
materialized views (which can increase performance)
point-in-time recovery
data partitioning
more flexible backup and restore options
the ability to use Win NT passwords and security (I know, that's not a big issue for most) PostgreSQL does have some support from third-party software. phpPgAdmin for example, is a great tool and gets better with each release. pgAccess is a tool that comes with PostgreSQL, but I haven't used it much in the last year or so, and I remember it feeling like it was not quite ready for prime time. But it's a Windoze front-end for the PostgreSQL server and that's a big deal! There are also a couple of books about it (with more on the way, I hope), one of which, Practical PostgreSQL, published by O'Reilly is very good and available online.
The biggest thing you get for all the money you spend on Oracle is a "known" product. There are hundreds of books on Oracle (many are awful--caveat emptor) as well as classes and trainers and consultants and DBA's everywhere in the world (repeat caution above).
I love PostgreSQL, enjoy working with it, and am delighted with the new functionality the developers chose to include in version 7.3 (almost like they read my mind). Face it, for most medium-sized projects, we create a connection to the database (I often use ODBC) and start firing off queries. It doesn't matter to our program which database is behind the connection. We want speed, efficiency, and safety for our data. Anything more is window dressing (or comfort for the suits). Long live PostgreSQL!
Oops, I'm going to get down-modded for editorializing... *sigh*
"an electronic catalog of images in multiple wavelengths spanning half the northern sky--100 million celestial objects in all, encoded in four databases...and combine it with other, smaller U.S. and international surveys, including some maintained by the United Kingdom, Australia, India, and European Union. "
"...optical telescope images and gamma ray, infrared, radio, ultraviolet, and X-ray snapshots of the heavens"
Now, that's a lot of data, in a lot of formats. Given the economics of software development and data transformation and conversion, I wonder what they'll be able to accomplish with $10M, beyond some XML data format definitions and some shiny new infrastructure (that gigabit network interface isn't cheap).
All in all, though, it seems like a good use for those tax dollars. The "Google" of astronomy research is an attractive idea, and I know we'll get some great new acronyms in the deal.
Over time data structures in a database are invariably found to be "less than conducive" to all the data and report requests that pile up on the typical DB specialist's desk. Some VP of marketing decides he needs a report that shows distributions of product lines by sales period or something. No problem, we create a tortured multi-table join, often with unions (oops, can't do that in MySQL, use intermediate tables instead), inner joins, and sub-selects (oops, can't do that in MySQL either, have to create some more intermediate tables), but eventually, voila, here's the new marketing report.
Now, everyone joins the VP-MKTG's bandwagon and wants their new reports compiled and summarized that way. In MySQL, without support for views, every query ends up having to be constructed again, including the tortured logic involved in having no sub-selects or unions. With view support, all we need to do is toss that awful query into a view, and select out of the view. It's not gorgeous, but it works. And you can even hand off the view to the other developers, so they don't get stuck in the quicksand of recreating the logic from scratch.
And now, because PostgreSQL supports functions that return datasets, we can toss all that logic into a function, and call that instead.
So, in answer to the question of what can PostgreSQL do that MySQL can't do: unions, subselects, views, functions. All are time savers. Lacking them, we can devise work arounds, but having them is very, very nice.
Perhaps "a year's worth" would be more clear. Regardless how obvious it seemed, they did not mean eight years (though it might be eight--or more--programmer years). I think the use of an apostrophe to indicate the possessive is optional in this case.
Enterprise noun def: an organization so large that the people who buy systems don't know how they work and so have to hire someone who does.
PostgreSQL can handle the 50 million rows provided the data structures are well-designed, and according to their press release they can handle the replication (it's always dynamic). The query rate of 2000/sec is more a question of the server hardware, server configuration, and network infrastructure than the database software per se. I don't know about "complex 3D boolean queries" but I know for a fact that PortgreSQL can process big, ugly, inefficient queries pretty well.
What makes M$SQLServer and Oracle more "suitable" for enterprises is their add-on tools (both have loads, though of varying quality) and the fact they maintain service centers for when the DBA throws up his hands and gives up. From my perspective though, the reduced licensing costs (even for large installations, we're talking about hundreds of $'s times thousands of users!) could pay for a lot of up-front hardware and ongoing code review. If I were starting a largish e-commerce project today, I'd start on Open Source just because or the reduced up front cost. You don't become among the richest people in the world by giving anyone a good deal.
Slashdot Mirror
Mine stops with an error at 2 gigs, believe me. Guess I've got to go jiggle the wires or something. The problem might be SAMBA. Or I have to upgrade from RH 7.2
In 1995, IIRC the biggest hard drive in common use was (quite a bit) less than a gig. It's not surprising the designers decided to use the smaller, more efficient 32 bit addressing. As in all other things related to computers in general (didn't billg once ask why anyone would need more than 640K of RAM, or is that urban myth?), needs change over time.
As hardware develops, the software develops to address it. I remember someone who was shocked that Lotus 123 could create a spreadsheet larger than a (320K 5 1/4" DS) diskette, because how could you save it?
We've come a long way. We'll go a lot further. 64 bit file sizes will seem small and quaint to our childrens' children.
Now, If I could just tar my Linux file system over to my son's spare 60 gig hard drive through SAMBA, I'd have cheap, fast, effective backup. But I have to do it 2 gigs at a time. Grrr... gotta go check up on that BSD stuff.
I've always been amazed that the big database vendors (Microsoft and Oracle for sure, IBM probably) got away with putting restrictions on reviews like this in their EULA's for years, but understood it to be a result of the complexity of configuring the products. That's why we don't see head-to-head comparisons of the major commercial database server products. A couple of small changes to a DB configuration can have a huge effect on the performance of the product, so the companies require their own engineers be on-hand to tune the config. Most publishers just don't have the time or resources required to set up a fair comparison review that fulfills the terms of the EULA. The only comparison reviews we see are published (in ads, mostly) by the vendors themselves. And they never say anything bad about themselves (or anything good about their competition). Sometimes it's the hardware vendors who publish benchmark results, and their purpose is to sell more hardware, not to enlighten end users.
What could possibly cause the same restrictions on anti-virus software? Could it be that difficult to configure? Or is the user above correct in inferring the software must be really bad? I suspect the reason the clause is in the EULA is that some lawyer thought they could get away with it and tried it. Now the court says no, and the vendor makes a pout and removes it. That means the laws work. Yay.
They demonstrated a tripling of the throughput of the machine with those soup-it-up fans! That's impressive. I'll bet that's better than the fan-and-heatsink donor got from his Athlon. It's too bad they couldn't get that "1 Roll eXtreme Duck Tape" to physically support the twin 120 volt fans to really cool off the beast. My experience with these (shredder) devices is that there is another metric besides raw throughput that makes all the difference in perceived "beastliness", and that's the speed of the feeder, analogous to the "first page" speed of a printer, except obviously the opposite. And as long as they have to run 120 VAC to it, they can add all sorts of lights and stuff. (For more 120 VAC computer projects, see etherkillers). Maybe with some tweaking they can hack a truly useful device that attaches to the output bin of a fast printer, and shreds as fast as the pages come out. Then they can haul away the incriminating evidence as fast as it's output.
As far as strictly data engine features go, Oracle has:
materialized views (which can increase performance)
point-in-time recovery
data partitioning
more flexible backup and restore options
the ability to use Win NT passwords and security (I know, that's not a big issue for most)
PostgreSQL does have some support from third-party software. phpPgAdmin for example, is a great tool and gets better with each release. pgAccess is a tool that comes with PostgreSQL, but I haven't used it much in the last year or so, and I remember it feeling like it was not quite ready for prime time. But it's a Windoze front-end for the PostgreSQL server and that's a big deal! There are also a couple of books about it (with more on the way, I hope), one of which, Practical PostgreSQL, published by O'Reilly is very good and available online.
The biggest thing you get for all the money you spend on Oracle is a "known" product. There are hundreds of books on Oracle (many are awful--caveat emptor) as well as classes and trainers and consultants and DBA's everywhere in the world (repeat caution above).
I love PostgreSQL, enjoy working with it, and am delighted with the new functionality the developers chose to include in version 7.3 (almost like they read my mind). Face it, for most medium-sized projects, we create a connection to the database (I often use ODBC) and start firing off queries. It doesn't matter to our program which database is behind the connection. We want speed, efficiency, and safety for our data. Anything more is window dressing (or comfort for the suits). Long live PostgreSQL!
Oops, I'm going to get down-modded for editorializing... *sigh*
All in all, though, it seems like a good use for those tax dollars. The "Google" of astronomy research is an attractive idea, and I know we'll get some great new acronyms in the deal.
Now, everyone joins the VP-MKTG's bandwagon and wants their new reports compiled and summarized that way. In MySQL, without support for views, every query ends up having to be constructed again, including the tortured logic involved in having no sub-selects or unions. With view support, all we need to do is toss that awful query into a view, and select out of the view. It's not gorgeous, but it works. And you can even hand off the view to the other developers, so they don't get stuck in the quicksand of recreating the logic from scratch.
And now, because PostgreSQL supports functions that return datasets, we can toss all that logic into a function, and call that instead.
So, in answer to the question of what can PostgreSQL do that MySQL can't do: unions, subselects, views, functions. All are time savers. Lacking them, we can devise work arounds, but having them is very, very nice.
Perhaps "a year's worth" would be more clear. Regardless how obvious it seemed, they did not mean eight years (though it might be eight--or more--programmer years). I think the use of an apostrophe to indicate the possessive is optional in this case.
imho
Enterprise noun def: an organization so large that the people who buy systems don't know how they work and so have to hire someone who does.
PostgreSQL can handle the 50 million rows provided the data structures are well-designed, and according to their press release they can handle the replication (it's always dynamic). The query rate of 2000/sec is more a question of the server hardware, server configuration, and network infrastructure than the database software per se. I don't know about "complex 3D boolean queries" but I know for a fact that PortgreSQL can process big, ugly, inefficient queries pretty well.
What makes M$SQLServer and Oracle more "suitable" for enterprises is their add-on tools (both have loads, though of varying quality) and the fact they maintain service centers for when the DBA throws up his hands and gives up. From my perspective though, the reduced licensing costs (even for large installations, we're talking about hundreds of $'s times thousands of users!) could pay for a lot of up-front hardware and ongoing code review. If I were starting a largish e-commerce project today, I'd start on Open Source just because or the reduced up front cost. You don't become among the richest people in the world by giving anyone a good deal.