Sun Eyes PostgreSQL 339
Da Massive writes "Sun is looking seriously into the database market - namely PostgreSQL. It says Oracle and IBM and even Microsoft licensing fees are way too expensive for the average punter.
This from John Loiacono, executive vice president of software: "We're not going to OEM Microsoft but we are looking at PostgreSQL right now," he said, adding that over time the database will become integrated into the operating system."
I doubt it (Score:3, Funny)
An NFL punter usually makes between $250k to $1M a year. They can handle most DB costs...
Re:I doubt it (Score:4, Insightful)
No, they can't. That is the problem...
Re:I doubt it (Score:3, Funny)
Re:I doubt it (Score:2)
Re:I doubt it (Score:5, Informative)
Also used to mean a gambler or a prostitues client!
Re:I doubt it (Score:3, Informative)
It's a British-ism meaning about the same as "bloke", only it can apply to men or women. Tends to have shades of "lowest common denominator" to it, meaning something like "an ordinary slob off the street picked at random".
Re:I doubt it (Score:3, Informative)
It's a British-ism meaning about the same as "bloke", only it can apply to men or women.
I've mostly heard it used/used it myself to describe "customers", particularly gamblers. As in "I had a punt on that nag but lost my shirt". I believe politicians use it to describe their electorate, but I couldn't possibly comment.
Disclaimer: I've only heard the term used in Scotland; it's usage elsewhere in Britain may be more/less general.
Re:I doubt it (Score:2)
I've mostly heard it used/used it myself to describe "customers", particularly gamblers.
Exactly. It means customer, not 'bloke' or 'average joe'. Since it's a slang word you'll only hear it being used colloquially, usually in terms of gambling, market stalls, bars, clubs, brothels, etc.
Re:I doubt it (Score:4, Informative)
punter == mark (Score:3, Informative)
Re:I doubt it (Score:2, Informative)
Re:I doubt it (Score:3, Informative)
Re:I doubt it (Score:3, Funny)
Re:I doubt it (Score:3, Informative)
Re:I doubt it (Score:5, Funny)
maybe these brits should go back to boiling every piece of food to death, instead of using stupid words on slashdot.
How are we supposed to know which words you understand? Are we psychic? Sure I know a few words like 'pants' that cause confusion, but to expect people to translate for you is just childish.
As for the food 'quip', how about four out of the top ten restaurants in the world [worldpress.org] being in Britain, compared to two in the USA.
Re:I doubt it (Score:2)
How many of 'em actually serve native British food?
Re:I doubt it (Score:2, Funny)
Re:I doubt it (Score:2, Insightful)
Re:I doubt it (Score:5, Funny)
Predictable (Score:5, Informative)
The only thing that slightly bothers me about their strategy is that Sun has been pushing their Java Systems hard. If they actually wanted to bolster that strategy, they'd have three major options for a Java Enterprise Database:
1. Cloudscape/Derby [cloudscape.com] - This product makes the most sense from a technology and licensing perspective, but the fact that it was an IBM product (even though Cloudscape was originally a separate entity before being acquired) taints the software in such a way as to make Sun look bad if they used it.
2. Daffodil [daffodildb.com] - This database is an excellent choice, but it would require the acquisition of another company, a move that the Sun shareholders might question. It would also bring quite a bit of flak in Sun's direction as Daffodil is an Indian company.
3. McKoi SQL [mckoi.com] - An excellent choice for a Java database, but lacks brand recognition. The feature levels and scalability of the database are still considerable questions. The GPL license also allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL.
As for the choice of Sunbird, I think it's simply a matter of "why not?" It's not like there's any particular leader in the market, and Sunbird plays nice with Firebird/Mozilla.
Java Enterprise System isn't all in Java... (Score:3, Informative)
Sun's Java Enterprise System is about programming in Java rather than the tools in Java. The technology of the product isn't hugely important its the fact that the API and development is in Java. Databases are clearly easy with Java as JDBC makes the actual choice a pure commodity. So what Sun want is a solid database, for free, that rounds out their platform effort and means that in one download and license a client can "get started"... which often means it is all they use.
Re:Java Enterprise System isn't all in Java... (Score:2)
Agreed. The only point I'm making is that having a Java infrastructure assists Sun in marketing the JES technology stack. If the entire thing is Java, and obtains a reputation for performance, reliability, and security, then it only makes Sun's Java strategy look better. With "native" components, critics are able to
Re:Predictable (Score:4, Informative)
1. Cloudscape/Derby - This product makes the most sense from a technology and licensing perspective, but the fact that it was an IBM product (even though Cloudscape was originally a separate entity before being acquired) taints the software in such a way as to make Sun look bad if they used it.
Derby is intended to be an embedded database, not a database server. Yes, they have a server mode, but can't hold a candle to MySQL, let alone, PostgreSQL.
3. McKoi SQL - An excellent choice for a Java database, but lacks brand recognition. The feature levels and scalability of the database are still considerable questions. The GPL license also allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL.
Since when can't you modify the source of a product with a BSD-based license? A BSD-based license is, in fact, far more liberal than the GPL because you can take the code, modify it, and close the source of the result. A perfect example is the Windows NT/XP TCP/IP stack -- stolen straight from BSD, and last I checked, Windows is not open source. In contrast to the GPL, where you have distribute any modifications you make and open-source any parts of your products that link to it. Hence, the description of the license as viral.
Speaking from experience, PostgreSQL is a grat product. Stable, reliable, and reasonably fast for medium to large scale, multi-user, distributed environments. The products listed above are all embedded databases intended for single user, micro environments. You are, in short, comparing apples to oranges.
Re:Predictable (Score:2)
If you could be so kind, could you clarify what you are referring to? I believe I said that "the GPL license allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL." I'm not certain where your vehemence is targetted.
Re:Predictable (Score:4, Insightful)
Smile when you say that, pardner!
"Stolen?" No, used legitimately. In fact, as I recall, you used to be able to look at the WinNT ftp client and read the credits to UC Berkely, which aren't even required any more.
"Stolen" just undermines your point that the BSD license allows -- hell, encourages -- this sort of use.
Of course, I think you misread the post to which you were replying, because that poster agreed with you that the GPL includes restrictions absent from BSD.
I'd also check again with regard to XP. I think the Redmond boys may have rewritten that stack by now.
Re:Predictable (Score:3, Interesting)
There's also PostgreSQL's estranged mother, CA Ingres [ca.com], the commercial version of Stonebreaker's original University Ingres. This is a well-vetted comme
Re:Predictable (Score:2, Interesting)
More like estranged cousin. The commercial version split off from the University version long before PostgresSQL.
Re:Predictable (Score:5, Insightful)
Depends, you can't exactly put a product like a RDBMS on a single scale. But in general it makes some sense to compare Postgres to SQL Server, but very little sense to compare either of those products with Oracle; although the limited attention span of most "decision makers" means that in practice the marketing departments of MS and Oracle play that game.
Oracle really really wants people to use Oracle for everything, and in truth you can use it for a lot of day to day database tasks, in the way you could use an eighteen wheeler to take your kids to soccer practice. Oracle's not very standards compatible. There's a million ways it traps you into their product. There's endless ways to shoot yourself in the foot, and getting things back requires a kind of black sorcery. In short, Oracle really sucks, unless it's the only tool that can do the job; in which case it's wonderful. Oracle's built so you can perform heart surgery on the patient while he's running a marathon, for the kind of applications where serious money is lost every time the database hiccups; the kind of applications where you have a team of DBAs who are paid six figures and it's a bargain.
SQL Server, to my mind, is mediocre. It's the choice of the departments who believe thing are easier if everthing comes from one vendor, and it's good enough to keep them out of too much trouble much of the time. From a DBA's standpoint I'd guess it's very easy to administer up to the point it becomes useless; if you never get there, you're happy. From a app develper's standpoint, it's pretty dreadful, but these days the style is to put as much as you can in the app tier so that doesn't matter much as it used to.
Don't know much about Postgres in production environemnts. It seems clean and I like the fact you have a choice of stored procedure languages.
PostgreSQL vs MSSQL vs Oracle (Score:5, Informative)
Don't know much about Postgres in production environemnts. It seems clean and I like the fact you have a choice of stored procedure languages.
I have had experience with both in production environments, and I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability. It is much better than MSSQL with concurrency and managing contention (MSSQL's locking strategy is quite brain dead). There is much more flexibility and power to create user functions and stored procs in PGSQL--you can do things like make user-defined AGGREGATE functions and data types in addition to having a choice of languages (none of that is possible with MSSQL). I find that all things being equal PostgreSQL is probably faster as well (largely an assumption becasue the PostgreSQL systems I've worked with are running on considerably less powerful hardware than the MSSQL systems I am doing). A lot of people comment about the ease of administration of MSSQL but I find that PGSQL really isn't that hard to manage even if you don't use GUI tools.
Oracle is certainly one step above PGSQL in power--but of course that comes with a very hefty price tag. That price isn't just in licensing either--Oracle takes more time to administer and you also pay by losing flexibility, since enterprise systems based on Oracle better do things the "Oracle way" or you are inviting trouble (just like with Microsoft products, Oracle really pushes its single-vendor solutions).
I have not played with Yukon/MSSQL 2005 yet, though I've heard a fair bit about it. From what I've heard it closes the gap a fair bit and comes much closer to PGSQL in terms of features and performance--it is supposed to handle locking/contention better and its has embraced
Re:PostgreSQL vs MSSQL vs Oracle (Score:3, Insightful)
By the way over the years I have been convinced that MSSQL developers follow postgresql development pretty close. They slowly seem to be adding all features postgres has to sql server. I bet they are even using a bunch of the same code.
Re:PostgreSQL vs MSSQL vs Oracle (Score:3, Interesting)
that might be true of v7.3 - when using postgresql 7.1 it was clearly not as easy to work with as MSSQL 2000. A perfect example was stored procedures - where you couldn't return a result list in postgresql, and the python stored procedure language required so many ticks and escapes it was impossible to use.
Regarding oracle, it used to be so much worse than it is today. For small databases it
Re:PostgreSQL vs MSSQL vs Oracle (Score:3, Insightful)
This can't be emphasized this enough.
We develop for/administer both, and it costs Oracle clie
Re:Predictable (Score:3, Insightful)
"very easy to administer up to the point of being useless"?
In the same way a car with no steering wheel is very easy to drive up to the point of you having to make a turn. SQL Server's very easy to administer because it only gives you control over the most rudimentary aspects of the database physical design, e.g. creating B+ tree indexes, moving entire tables between databases etc. If this is the limit of the kind of adminsitration you do, then you really can't find an easier to
Re:Predictable (Score:2)
Indeed, someone has already started it http://plj.codehaus.org/ [codehaus.org]
Derby (Score:2, Informative)
Sun used to bundle Cloudscape before IBM bought Informix, and subsequently switched to Pointbase. For App Server 9/G
Hmmm. I'd honestly have thought... (Score:2)
Alternatively, have a database-independent wrapper and sell any of the popular Open Source databases according to customer needs. That leaves the door wide open to transparent, painless upgrades (always a good money-spinner) AND winning more hearts amongst those developing a phobia of lo
Re:Predictable (Score:2)
That hasn't stopped people before.
integrating into the OS (Score:3, Interesting)
Re:integrating into the OS (Score:5, Informative)
Actually, I'd say that the technical shortcomings have a LOT to do with it. PostgreSQL can be placed head to head with Oracle and still pretty darn appealing. MySQL really don't have that capacity (yet), and is hampered by its non-ANSI comaptible design and SQL variant. So I'm not certain that the decision was made entirely on licensing alone. After all, Sun does support the GNOME project as well, and that is solidly under the GPL.
Re:integrating into the OS (Score:3, Informative)
Actually most of the GNOME is licensed under the LGPL.
Re:integrating into the OS (Score:2)
Combined with in a blade or other server format, SUN should be able to unit that smokes the others on TCO basis, and can be advertised at a fixed dollar price, w/o additional license fees.
Re:integrating into the OS (Score:2)
So if someone else does this, it is an avantage of open source, but if Sun does this....
Once again, BSD == good (Score:4, Insightful)
I've had people contribute code to PMD and say they were only contributing it because they felt the BSD license avoided any possible obligations on their part. And the products [sourceforge.net] that are based on PMD? Just means more books sold [pmdapplied.com]. Good times!
If everyone has to re-write the fix ... (Score:2)
Nope. While it is true that more people can use the code and fix bugs ... there is nothing saying that those bug fixes must be released to the general public.
So if Sun fixes a bug, they don't have to release that fix to anyone.
So the bug will still exist in the base.
This is what leads
Re:If everyone has to re-write the fix ... (Score:2)
This is in keeping with the fact that BSD folks toil away on code for which they can't expect to charge any money.
Re:If everyone has to re-write the fix ... (Score:2)
What does that have to do with anything? The "BSD-license loving programmers" aren't the ones deciding whether to release the fixes or not; Sun is the one deciding that. Without the GPL to force it to release the fixes (if and only if it distributes the fixed program to begin with), it's quite likely that it won't do so, because its share
Re:If everyone has to re-write the fix ... (Score:2)
That's the freedom RMS and company don't want you to have.
Besides, it's not like fragmentation isn't a hugely rampant problem in the GPL-based world. Unusually, the
Re:If everyone has to re-write the fix ... (Score:2)
Not to be overly critical, but maybe you should provide some real proof before making such claims.
Re:If everyone has to re-write the fix ... (Score:5, Insightful)
True, on the surface. However, if they don't then the next time someone modifies that bit of code, then they will have to re-merge their changes. If someone else fixes the bug in a different way, they have to do code review on both implementations and then decide what they want to keep.
There is a reason people like Apple contribute to BSD projects - it's cheaper to get your patches merged upstream than to maintain a fork.
So? (Score:4, Insightful)
I've had people contribute code to PMD and say they were only contributing it because they felt the BSD license avoided any possible obligations on their part.
Just like there's plenty of people who only contribute to GPL projects since they don't want "evil corporations" stealing their code.
You can find fanatics driven by ideology rather than common sense in both camps. That's hardly something to cheer about.
Sungres (Score:2)
Question (Score:3, Insightful)
I like the BSD license, and I understand what the ramifications of it are. And I'm not trying to start a debate over whether this is a 'good' thing or not. Just hoping someone here more knowledgable will give some insight on how this is likely to go.
Re:Question (Score:5, Insightful)
Well, they don't have to give anything back, if postgres is BSD-license. But in practice, they probably will. Not everything, but quite a bit. It's in their interests to give back to the community a lot of the changes they've made, so that the work done on the free version doesn't unnecessarily duplicate the proprietary version, and so that the next release of postgres doesn't force Sun to rewrite half their modifications. Basically, if Sun want to take advantage of progress made by the community on postgres, then they'll be giving back some of their own. They don't want to diverge too far.
Re:Question (Score:2)
I think the postgres development community is strong enough that it doesn't matter. So I'm not worried about it, I just am curious about the implications of that one aspect.
Fragmenting might be in their best interests. (Score:3, Interesting)
The same situation exists here. Sun is not legally bound to release any improvements back to the base, but can legally use any improvements that others provide to the base.
Re:Question (Score:2)
License comparison (Score:2)
Maybe they'll bundle a toolbar? (Score:2)
I wonder if he means a database-oriented filesystem? There's no real reason to stop there... system and application configuration data in a database would be great.
As much as I love PostgreSQL, I think it might be kinda heavy for that kind of implementation.
Re:Maybe they'll bundle a toolbar? (Score:2)
Yeah. Like Windows' Registry?
Re:Maybe they'll bundle a toolbar? (Score:2)
It's not a bad concept. I personally like the OS X method better, since it (at least in theory) better compartmentalizes individual applications, but when you get down to it what sucks about the Registry has more to do with the fact that it's on Windows than the concept itself.
Re:Maybe they'll bundle a toolbar? (Score:2)
I wonder if he means a database-oriented filesystem? There's no real reason to stop there... system and application configuration data in a database would be great.
I don't know about whether DB oriented filesystems would be useful.
However, as it is on most Linux systems, it seems like there are 27 different programs, all with their own poorly implemented db. It would be nice to have one DB to take care of everything, at least in theory.
On my machine I have slocate, apt-rpm, rpm and gconf, just off the top
This is more realistic (Score:4, Insightful)
Again, open source DBs have a chance because not every user works with them directly. Also, the interface, SQL, is a much more standardized interface than with an OS. As a programmmer, writing queries to DB A is pretty darnd exactly like writing queries for DB B. So, I think that their will be much better competition in the database world as in the OS world.
The other half of the article - Sunbird (Score:4, Funny)
Firebird anyone? (Score:2, Interesting)
How do they compare? (Score:2)
Re:How do they compare? (Score:4, Interesting)
Not true, sql server is a fine database. Its problems have more to do with being excessively gui-driven, expensive compared to OS dbms, and owned by microsoft than anything about the speed.
> and I'm wondering whether I should suggest they go with PostgreSQL instead
not having benchmarked them, i would guess that sql server would be faster on the same hardware.
> Do you still need to VACUUM your databases?
I think an automated vaccuum has been created. But it was never a real issue in my opinion anyway - basically the existance of vacuum enables postgresql to speed deletions and updates - since some table maintenance can be performed asynchronously. So, cron (or task schedule) the thing to run nightly and you're fine.
> Has MySQL grown up yet (i.e. implemented the features it has been missing, compared to standard SQL)?
Not yet, but it's getting there. 5.0 should be a big improvement, but it still has a long way to go - not necessarily implementing the essential feature set, but now making those implementations robust.
> How does Oracle's performance compare to the rest?
Depends on what you need to do: have a small database, or a medium-sized database that's purely transactional? The open source databases can do the job. But if you've got a large database, or want to do some analytics (like show simple trends of data) then oracle/db2/informix are your friend. These commercial databases can easily be 40x the speed of postgresql or mysql on the same hardware for analytical queries.
Smart path for Sun (Score:3, Funny)
True, it is not written in Java, but neither is Solaris. Sun uses Java pragmatically, as everyone should, and since there are JDBC drivers for Postgresql, it really doesn't need the database written in Java.
I think it's a smart move, and this news combined with the Google collaboration is giving me hope that Sun's management has suddenly woke up and smelled the coff... er I mean java.
What happened to Clustra? (Score:4, Insightful)
Sun gained an excellent database when they acquired Clustra. What happened to it and why are they now talking about Postgres? Are they really that intent on pissing away that investment?
Re:What happened to Clustra? (Score:3, Interesting)
If you'll excuse the shameless link, I've written up my thoughts in more detail here [leyton.org], and in the last /. post on the "SunDB" matter back in Feb [slashdot.org], a bit of agreement was to be found on the Clustra theory [slashdot.org]. My disclaimer is, I suppose, that I've worked with and used Clustra, and live in hope Sun will see the sense of their purchase.
Is it just me? (Score:2)
When MS integrates Access into Windows, they will have NO customers left... IMHO
Hmmm. (Score:5, Insightful)
Otherwise, it seems a bit curious to me, because it juxtaposes two things that don't seem to go together in my mind: High end database management and penny pinching. Prices for Oracle on low end hardware (x86 servers) are not high at all, certainly not high enough warrant any concern at all in any project that doesn't get staff and DBA time free. Once you pay for a couple of professional staff the Oracle license fees are not worth worrying about, if they are even a bit more productive. Prices for Oracle on big iron are shocking to people whose idea of a big software procurement is a couple of dozen boxes of MS Office, but in those environments they are likewise not out of place.
Oracle's licensing model is incredibly byzantine. It takes days of study to get your brain around it. Once you do, what's obvious is that it is a reflection of the company itself: it's a complex machine designed to squeeze every last marginal dollar out of the customer. But -- the reason it works is that the prics are very carefully calibrated so you don't really save any money by going to the competitor. For example, if you just grab the biggest license you can on the x86 platform to make your life simpler, you will pay dearly. But if you are selective and understand the model resaonably well, Oracle is about the same or perhaps even cheaper than SQL Server on equivalent machines. Of course if you don't know what you're doing you'll be accidentally sending Oracle beaucoup bucks, like CA did a few years ago. I assume midrange and high end licensing for Oracle are the same: they maximize Oracle's revenue for the specific capabilities you license from them, and it behooves you to choose wisely.
Of course, no pricing model works for everyone. Perhaps there are people on high end hardware who just need something that is very fast and very reliable, not highly configurably fast and as reliable as human ingenuity can make it. Which leads me to a conclusion:
Talking about Postgres in the context of Oracle and DB2 is probably just posturing. It would be years, if ever, before Postgres gets the kind of features that make Oracle a must have for many high end applications. So I'm guessing this is really aimed at delaying the encroachment x86/Windows/SQL Server on the midrange, by giving a big vendor seal of approval to Postgres, which is plenty good for the kinds of apps you run on SQL Server, and quite a bit better if the hardware is better.
Re:Hmmm. (Score:5, Informative)
Actually that's not remotely true. We're not talking about MySQL here. PostgreSQL is quickly gaining all the "high-end" features of Oracle: tablespaces, failover, replication, etc. In some cases, they aren't yet as fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly coming into its own.
On top of this, it's a lot less painful to work with, and the SQL featureset is far nicer. After having worked with them both on a daily basis, the only reason I'd willingly use Oracle is if I was working with terabytes of data and had lots and lots of money to throw at Oracle to make it work and support it. Which I don't. Like Sun is saying, this is unjustified for most people.
Re:Hmmm. (Score:3, Interesting)
Remotely true? It depends. High end is a logarithmic scale isn't it? And it's a moving target. I'd say the very idea of "High End" is only vaguely useful. If you need the fine grained control of the physical database Oracle gives you, then PG isn't high end enough. And it doesn't matter if a particular feature exists if it doesn't exist in the form you need it to. On the other hand, if PG does what you need, then you're better off without the cruft.
On top of this, it'
Re:Hmmm. (Score:5, Informative)
> PostgreSQL is quickly gaining all the "high-end" features of Oracle:
> tablespaces, failover, replication, etc. In some cases, they aren't yet as
> fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly
> coming into its own.
Hmmm, as much as I like postgresql I don't see it that way:
1. replication? it's most often used as a clunky way of implementing failover - yuck. In my large data architectures, replication is almost never used: it's almost always the worst solution to some problem.
2. tablespaces? yep, they're good things to have. that's fine - i think oracle and db2 have supported them for around twenty years, so it's hardly high-end technology tho.
3. failover? ok, this is critical - but there are also many different forms & flavors. I'm not familiar with what postgresql has so I won't comment - other than to say it needs to be rock-solid.
ok, how about a few more:
4. memory management: a high-end database should give you a ton of control over how memory is handled - especially when you plan to buy tons of it. Here the big databases allow you to assign different amounts of memory to different buffer pools, which are then assigned to different tablespaces. These bufferpools (caches) are how to easily ensure that hits against some tables or indexes occur 99% of the time from memory, and others 50% because they're so much larger. I'm pretty sure that neither postgresql or mysql can do this.
5. process management: in db2 your application writes to a buffer pool, an asychronous agent picks up that change and writes it to a log file, another asynchronous agent picks it up and writes it to the table. This heavily-asychronous behavior (and yes, with memory & processor tuning available for each agent type) allows you to maximize write-throughput. Postgresql and mysql are still in the slower sychronous world.
6. parallelism: in mysql and postgresql all queries are single-threaded. In db2 and oracle a large query will actually split itself up into multiple sub-queries to maximize throughput for multiple cpus and storage arrays. This provides db2 & oracle with linear performance improvements up to 4-8 cpus. In othe words, large queries that perform table scans can take advantage of SMP hardware for the commercial products - and cut down your query time by 75% on a 4-way compared to mysql and postgresql.
7. partitioning: btree indexes only work for very selective queries - like when you want 1% or less of the data of a table. But for many queries you need to crunch 5,10,or 15% of the data. That's where range partitioning comes in: you just scan the data you absolutely need to. So, while db2 or oracle are scanning 10% of the data - postgresql or mysql still have to scan 100% of the data. That would result in a 10x increase in speed over postgresql or mysql.
that's just off the top of my head - given a little time this list would double.
Postgresql is a fine tool, and it has all the technology that db2 or oracle had 12-15 years ago. And that's a cool achievement, and qualifies it do a ton of cool projects. Plus, with time it will catch up. But it still has a *long* way to go.
Re:Hmmm. (Score:5, Informative)
Yeah, Postgres doesn't currently support this. IMHO it isn't that useful -- the performance improvement I'd expect would be pretty small (for one thing, all Postgres buffering is done in addition to the kernel's buffering, so the net impact will be smaller). It also adds a significant administrative burden -- you need to configure which objects go in which pools, as well as how large each pool is.
DB2 may well be better than Postgres here, but your explanation above doesn't make a lot of sense. In Postgres, a committing transaction only needs to wait for the WAL record describing the transaction to be flushed to disk (multiple transactions that commit concurrently can be flushed via a single fsync(2)). That is the only I/O that needs to be done synchronously -- the rest can be done async (notably, this includes the table I/O itself -- the modified buffers are just marked dirty in memory and are subsequently flushed to disk). Note that a backend may also need to wait for dirty pages to be flushed from the buffer pool if it is trying to replace a dirty page with a clean one, but (a) those flushes are done via write(2), so there is not necessarily a disk flush involved (b) the background writer in 8.0+ is intended to resolve this by ensuring that most of the work of flushing dirty pages is not done by a normal backend.
PostgreSQL 8.1 (currently in beta) includes "constraint exclusion", which is essentially a primitive form of table partitioning (using inheritence and check constraints, you divide the data into tables with distinct check constraints; the optimizer has been improved to recognize when a child table can be omitted from the query plan by looking at the check constraints involved).
Re:Hmmm. (Score:3, Insightful)
For true high end applications this may be true, but for what >90% of Oracle customers actually need, they could switch to PostgreSQL without sacrificing speed, features, or flexibilty, and they could do it while saving not only on Oracle licensing fees but also on the six figure salary Oracle
OS Integration is a great idea (Score:3, Interesting)
I personally think every OS should ship with some sort of a light db engine equipped to handle databases stored in files. Imagine if you could write a simple application that opened databases just like you would with a db server, only using a file instead. When it comes time to scale it to a larger application, switch one line and connect it to a server instead. Or have your application configurable so that the user can either store it in a file or on a remote server simply by changing the server info from "c:\database.db" to "server:1234".
Re:OS Integration is a great idea (Score:3, Informative)
Re:Let the PostgreSql vs MySQL Debate Commence (Score:2)
Anybody can guess where I stand in this debate (hint: look at my slashdot username).
Re:Let the PostgreSql vs MySQL Debate Commence (Score:2)
Re:Let the PostgreSql vs MySQL Debate Commence (Score:3, Funny)
Re:Let the PostgreSql vs MySQL Debate Commence (Score:2)
LOL, I think we know where you stand in the flame war, don't we?
Re:Let the PostgreSql vs MySQL Debate Commence (Score:5, Informative)
Re:Let the PostgreSql vs MySQL Debate Commence (Score:2)
Re:PostgreSQL vs MySQL (Score:5, Informative)
PostgreSQL > MySQL; but MySQL is improving it's feature set
SQL3:
PostgreSQL > MySQL; PostgreSQL has a few SQL3 features
Speed:
PostgreSQL ~= MySQL; sometimes faster, sometimes not
Database\table\row\... Size:
PostgreSQL > MySQL; PostgreSQL has less size restrictions, or at least, the limits are much larger than those of MySQL
Stored Procedures:
PostgreSQL > MySQL; MySQL not yet, but in 5 they have SQL:2003 like stored procedures; PostgreSQL has SQL, C, pgSQL, Tcl, Perl, Python and roll-your-own and a few not bundled with PostgreSQL
Installation\maintenance:
MySQL > PostgreSQL; MySQL is easier to set up
OS Support:
PostgreSQL ~= MySQL; postgres came a long way, e.g. there's now a stable Windows version.
Re:PostgreSQL vs MySQL (Score:4, Funny)
Yes indeed, now if only there were a stable Windows platfrom on which to run it.
Re:PostgreSQL vs MySQL (Score:5, Funny)
> MySQL > PostgreSQL; MySQL is easier to set up
PS, this doesn't hold up on Debian systems:
apt-get install mysql-server
vs
apt-get install postgresql
the latter is less typing.
Re:PostgreSQL vs MySQL (Score:3, Insightful)
Uh, yeah. I think he was referring to the configuration steps after that to get the server running. I personally find PostgreSQL easier (just edit the security configuration files and initialize a database, whereas MySQL makes you jump through hoops inside the master database), but from a zero to executing perspective MySQL is up faster than PostgreSQL.
Re:PostgreSQL vs MySQL (Score:3, Informative)
I don't think this is much of an issue, I recently installed postgreSQL on my Windows XP machine in order to try it out. The installation was 100% simple and painless.
Re:PostgreSQL vs MySQL (Score:4, Informative)
Re:PostgreSQL vs MySQL (Score:5, Informative)
The biggest one that has made a difference in my life lately:
Table Partitioning:
PostgreSQL > MySQL; Mainline PostgreSQL has table partitioning as of 8.1-beta, by leveraging inheritance (Postgres is an Object-Relational Database).
Queries on the aggregate of the partitions are directed at the parent table, and optimized to only look into appropriate sub-table by checking CHECK constraints of the sub-table against the query WHERE clause.
Basically, you do it like this (contrived, but related to how I'm using them at the moment):
MyBigFatTable stores timestamped data from a bunch of a machines at regular intervals, keying off of the machine id and the timestamp of the data:
CREATE TABLE MyBigFatTable (
machineid INTEGER REFERENCES machines(machineid),
stamp TIMESTAMP,
data_x FLOAT,
data_y FLOAT,
[... lots more data fields
PRIMARY KEY (machineid, stamp)
);
Your problem is, the table size grows and grows and grows unbounded, and database operations continue to get slower and slower (inserts, updates, and selects) as the table grows. You have a policy to expire the data after a month which limits the maximum growth, but this in turn requires lots of deletes happening all the time, which again hurts performance.
The inheritance-based partitioning solution is to leave that table definition as it is, and also define:
CREATE TABLE MyBigFatTable-2005-10-05 (
PRIMARY KEY (machineid, stamp),
FOREIGN KEY (machineid) REFERENCES machines(machineid),
CHECK ( stamp >= '2005-10-05 00:00' AND stamp '2005-10-06 00:00')
) INHERITS MyBigFatTable;
As you can see, the column definitions are inherited, but you must re-specify the PK/FK stuff. The added check clause says that only data from Oct 10, 2005 is valid in this subtable.
You set up a maintenance script to create your new time-based tables ahead of time (say once a day create tables for the next day), and you do your data INSERTs into the specific subtable (you know the timestamp of the data you're inserting, so you can generate the appropriate table name from that (MyBigFatTable-2005-10-05).
You run your SELECTs against the original MyBigFatTable just as you did before. It automatically includes any rows from its child tables. Further, if your SELECT's WHERE-clause was constraining a query to a specific time-range, only those children of MyBigFatTable whose CHECK constraint indicates they could possibly have relevant data are checked.
And as for the problem of expiring data and the delete traffic you had before? You simply drop the old child tables with "DROP TABLE" from a maintenance script when they're a month old - no DELETEs neccesary.
Re:PostgreSQL vs MySQL (Score:5, Informative)
A quite legnthly comparison can be found here. [arvin.dk]
SQL92 compliant is a relative term.
Re:Too late. (Score:2)
Re:BTrieve??? (Score:2)
One thing that's always been nice about Pervasive, though, is that tech managers usually have a warm-fuzzy feeling about it, since many of them used Novell back in the day. It's often quite easy to get to get approval for it, especially when the tech manager was otherwise trying to cram something else down your throat.
Re:Sun? PostgreSQL? (Score:3, Informative)
Telstra are also a big Microsoft customer and also a big Linux user. They use IBM GSA extensively too. What's your point?
I know one guy who worked on an implementation of part of the Telstra Mobile billing system for IBM GSA as Telstra found out that they weren't cathing the milliseconds to seconds in cell switch time and therefore billing users for it.
This just like the comment in the article is just padding. It doesn't really add anything to
Re:MSDE is free! (Score:2)
Incidentally, Microsoft SQL Server holds the honor of being the host for the fastest distributed Internet worm.
Re:MSDE is free! (Score:2)
See? It does scale. How many other databases can handle that many transactions per second?
Re:MSDE is free! (Score:3, Insightful)
...as in beer, which makes it pretty much useless for many projects - such as a competitor integrating it into their OS.
Re:PostgreSQL vs Mysql (Score:2)
Re:PostgreSQL vs Mysql (Score:3, Interesting)
> I've used both views and subqueries with MySQL recently. stored procedures are
> listed for V5.
Views are listed as a new feature in 5 - which is just a development release. So, yes - the original poster was correct on that account.
MySQL picked up sqlqueries in V4.1, though I haven't checked to see how well they implemented them: ie, can you:
- select (select max(date) from a)
- select blah