Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What Is New In PostgreSQL 9.0

CmdrTaco posted more than 4 years ago | from the better-than-prestgresql dept.

Databases 213

Jamie noted a blog that says "PostgreSQL 9.0 beta 2 just got released this week. We may see another beta before 9.0 is finally released, but it looks like PostgreSQL 9.0 will be here probably sometime this month. Robert Treat has a great slide presentation showcasing all the new features."

Sorry! There are no comments related to the filter you selected.

In place upgrades (0)

wannabe (90895) | more than 4 years ago | (#32512862)

I'm glad to see work being done on on-place upgrades rather than the current dump and reload.

(First Post?!?)

Re:In place upgrades (2, Informative)

GooberToo (74388) | more than 4 years ago | (#32513096)

You're not alone. That issue is one of the last MySQL staples which PostgreSQL users hear about.

Re:In place upgrades (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32513240)

More liek MyFailQL amirite?!?!

Re:In place upgrades (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32513314)

black people are about 13% of the US population yet they appear in easily 80% of TV commercials, often outnumbering anyone else. and you're not supposed to notice, and heaven forbid if you point this out or question it in any way. welcome to political correctness. questioning the benevolence of its purpose or of its subtle propaganda methods, comparing them to the merits of openly stated goals and methods, or questioning the social engineering of society and whether the people who wield that power really have our best interests at heart would all make you a heretic. it is like george bush and "with us or against us". there is no such thing as drawing a distinction between treating all humans as equals and political correctness, the orthodoxy of this religion state that they are always one and the same and rejecting one means rejecting both. mindless sheeple, when will you wake up and realize that good honest things don't have this character?

Re:In place upgrades (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32513996)

Maybe those 13% of black* people have 80% of the wealth? LOL sorry, I couldn't resist!

* they're not african-americans, just as I'm not european-canadian. They're also not "black" anymore than I'm "white". They're brown and I'm a pinkish hue.

Re:In place upgrades (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32514738)

Would have modded you up if I had points pink guy

Re:In place upgrades (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32515840)

Great, Andorians with Slashdot accounts now.

Re:In place upgrades (0, Offtopic)

Toonol (1057698) | more than 4 years ago | (#32515870)

black people are about 13% of the US population yet they appear in easily 80% of TV commercials

If there's an average of 11 people in a TV commercial, that number makes perfect sense. 0.87 ^ 11 = .21

Re:In place upgrades (4, Informative)

Trifthen (40989) | more than 4 years ago | (#32513582)

Actually, there's a utility that works on 8.3 and above: pg_migrator, and isn't really that new. I wrote a long article [bonesmoses.org] on it a while ago that covers how we used it, and most of those instructions are not especially specific to our use case. Of course, before 8.3 you'll have to rely on a parallel restore (8.4's pg_restore client has a -j flag much like make, that will load several tables simultaneously, which drastically cuts migration time except for the initial dump.)

All in all, it's a much better DB than it was in the 7.x days, and that's after the drastic improvements in the 8.x tree. I can't wait for 9.0.

Re:In place upgrades (1)

TheSunborn (68004) | more than 4 years ago | (#32513920)

Is there any specific reason you did not just download the postgresql binary from their website, instead of building it yourself?

Re:In place upgrades (1)

Trifthen (40989) | more than 4 years ago | (#32516302)

If you'll read the section I have on rebuilding the RPMs from source, you'll notice I say this:

The Official RPMs supplied by Postgres are insufficient for our needs. For pg_migrator to work, we'll need to build new ones.

Followed closely by:

. . . will disable integers from having datetimes assigned . . .

And later, you'll notice my configuration/build flags:

./configure --prefix=/opt/postgres-8.4 --disable-integer-datetimes

That last one, '--disable-integer-datetimes' is required for pg_migrator to work. This flag is, unfortunately, not set in the default binaries distributed by PostgreSQL.

SQL! (5, Funny)

Anonymous Coward | more than 4 years ago | (#32512874)

select FIRST_POST from slashdot where user='Anonymous Coward';

Re:SQL! (3, Funny)

medcalf (68293) | more than 4 years ago | (#32513546)

SQL ERROR: inconsistent indices

Re:SQL! (0)

Anonymous Coward | more than 4 years ago | (#32514190)


SELECT comment.* FROM comment
JOIN user ON comment.author = user.id
WHERE comment.sid='1612246' AND user.name='Anonymous Coward'
ORDER BY comment.cid LIMIT 1;

Re:SQL! (1)

AttillaTheNun (618721) | more than 4 years ago | (#32516416)

update slashdot set user = 'AttillaTheNun', comment="First Post!" where post_id == 1 and user 'AttillaTheNun';

-- 2. Profit!

Re:SQL! (1)

AttillaTheNun (618721) | more than 4 years ago | (#32516460)

I know, SQL ERROR

Slashdot pseudo HTML markup escape FAIL.

If you got tired of clicking through articles (4, Informative)

Qzukk (229616) | more than 4 years ago | (#32512876)

While the changelog is cool and all, if you just want to see the slides go to http://www.slideshare.net/xzilla/intro-to-postgres-9-tutorial [slideshare.net]

Re:If you got tired of clicking through articles (0)

Anonymous Coward | more than 4 years ago | (#32514170)

While the changelog is cool and all, if you just want to see the slides go to http://www.slideshare.net/xzilla/intro-to-postgres-9-tutorial

Thanks. I just want to see the slides, though, and when I tried to download the presentation, I was told that I'd have to sign up for an account and that I'd get it by email (!).

Can anyone please put this up on a non-braindead site?

Join removal is cool (2, Informative)

wandazulu (265281) | more than 4 years ago | (#32512972)

This bites me occasionally in Oracle where you've got a big query that has lots of tables joined together, and then at some point one of the columns is removed from the select part, and the query performance suddenly goes to hell. Then you have to go through and verify that each table is actually being used (even worse if the column that was removed from the select came from deep joins).

Go Postgres!

Re:Join removal is cool (4, Insightful)

interval1066 (668936) | more than 4 years ago | (#32513272)

"Go Postgres!"

Indeed, PostgreSQL is such a great system, in a lot of ways its better than mySQL; I'm constantly amazed by the number of orgs that have never heard of it.

Actually (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#32515164)

postgres is a slow piece of shit, mysql is way better.

Re:Join removal is cool (1)

Joey Vegetables (686525) | more than 4 years ago | (#32516034)

I know this will be interpreted as a troll, but I'm asking, in all seriousness, in what way(s) is the current production version of PostgreSQL NOT a better RDBMS than the current production version of MySQL? Or, in other words, where does PG need to improve in order to match MySQL?

Re:Join removal is cool (1)

deuterium (96874) | more than 4 years ago | (#32516180)

Isn't it odd? It's been around forever, works on many platforms, and supports just about any feature you might need. I started using it a few years ago for a scientific simulation project, and I haven't looked back. I think the main hindrance, in a circular argument manner, is that is hasn't been as popular as MySQL, so there're a smaller community. It wasn't as easy to find a good PL/pgSQL book as it was to find material for all the others.

My only other complaint would be the relative immaturity of the pgAdmin software. It works fine, but does some odd things like doubly importing data if you don't know not to click the OK button after completion, and not refreshing views after actions.

Color me skeptical. (4, Interesting)

Estanislao Martnez (203477) | more than 4 years ago | (#32513346)

This bites me occasionally in Oracle where you've got a big query that has lots of tables joined together, and then at some point one of the columns is removed from the select part, and the query performance suddenly goes to hell. Then you have to go through and verify that each table is actually being used (even worse if the column that was removed from the select came from deep joins).

Do you have an actual example? I simply don't see how removing a column from a select clause would make a query slower, unless you're talking about uses of aggregate functions, and even there I'm having a hard time seeing how a removal could make things worse.

The thing that determines how much work the database has to do in order to produce the results is the FROM, the WHERE and the GROUP BY, because those are the ones that determine what's going to be accessed, joined, sorted and how. The SELECT (except for the use of aggregate functions) primarily just decides what information to present from the join results and how to present it.

Re:Color me skeptical. (3, Informative)

Anonymous Coward | more than 4 years ago | (#32513692)

you are basically correct, but yet still wrong. Certain optimizations use page reads to improve performance when returning a result set. It will try to access pinned/blocked columns before accessing trivial columns there by reducing collection times. Although these columns may not be indexed per se, they are ordered so retrieval pretty much sequential. Removing those pinned columns (either from the query or from thjs DB in general) may cause the DB to to start 'thrashing' and reduce the performance. This is another reason why vectored indexes are a good thing.

Re:Join removal is cool (1)

mcferguson (733767) | more than 4 years ago | (#32513560)

Note that join removal is only going to work on OUTER joins in some cases, as an INNER join is implicitly part of the predicate. If the joined columns are already related by a constraint, though, it may still be able to eliminate an INNER join.

Re:Join removal is cool (2, Informative)

mcferguson (733767) | more than 4 years ago | (#32513656)

Actually, here are the entire conditions for join removal (from Robert Hass's blog [blogspot.com] ):

(1) it's a left join, (2) there is a unique index on all or a subset of the join columns, and (3) none of the attributes from the nullable side of the join are used elsewhere in the query

Re:Join removal is cool (1)

Kjella (173770) | more than 4 years ago | (#32514508)

For now, the more interesting part is this part:

We can't skip joining to any of the other tables, because those are inner joins. That's an implementation restriction which I hope will be lifted in PostgreSQL 9.1, but some more logic is needed to make that safe.

Not sure exactly how he's going to pull that off since a join can remove rows, but if you join on a unique index you should be able to do it just using the index without touching the table itself which should be very fast.

Re:Join removal is cool (0)

Anonymous Coward | more than 4 years ago | (#32515316)

Last I checked the indexes don't contain transaction data (from 2007: "why is count(*) so slow?" [postgresql.org] ) so if you just looked at the index, you might still get the wrong answer. Maybe adding transaction windows to indexes is what this is waiting on? (can't see that not suck either performance-wise or storage-wise though).

Re:Join removal is cool (1)

mcferguson (733767) | more than 4 years ago | (#32515556)

You would need an FK to the other table's unique index / PK, and then the inner join could be removed (if it is not referenced in the select list). In theory the FK has already been checked so the join is not really acting as part of the predicate / filter in that situation.

Built-in replication (4, Interesting)

atomic777 (860023) | more than 4 years ago | (#32513250)

A better summary of the changes is here [postgresql.org] .

After years of resisting, one of the more significant changes is the inclusion of WAL shipping-based replication into postgresql core, and the ability to do read-only queries on the standby systems. This will hopefully go a long way towards appeasing mysql users used to the "easy" replication that mysql provides.

Re:Built-in replication (4, Interesting)

BSAtHome (455370) | more than 4 years ago | (#32513570)

And streaming replication. It makes it a lot easier to have a backup server that is up to date. It makes me happy so I can do partial restores without a lot of fuss.
Now, if only the enterprise apps could find out to reconnect to the database and continue where they left off without crashing and trashing.

Re:Built-in replication (1)

tweek (18111) | more than 4 years ago | (#32515696)

If an application (enterprise or not) doesn't have a mechanism that handles stale connections(connection pool or not), it might not want to call itself an application.

Seriously.

Re:Built-in replication (1)

Bovius (1243040) | more than 4 years ago | (#32513734)

Yes! I cried out in jubilation when I heard they finally included proper "read-only slave" replication in the next major relese.

This has been the shameful shortcoming of Postgres for a long time.

Re:Built-in replication (2, Insightful)

atomic777 (860023) | more than 4 years ago | (#32513984)

I see the replication feature as being more about perception than anything else.

Postgresql has long had a variety of replication options [postgresql.org] outside of the core that serve various needs, but it seems that the perception out in the community remained that postgresql was a stable, stand-alone database, and getting replication to work on top involved "hacks", while mysql, despite its faults, had "solid" replication that lent itself better to large installations.

Of course this perception is far from reality, but it has been deemed a serious enough problem for the postgres team to finally include replication in the core.

Re:Built-in replication (1)

Slashdot Parent (995749) | more than 4 years ago | (#32515570)

You're representing slony as anything other than a fragile, unscalable, dirty hack? Wow, just wow.

I'll be interested to see how native replication performs. Including it in core was long-overdue, and I'm glad they finally got it in there.

Re:Built-in replication (1)

GooberToo (74388) | more than 4 years ago | (#32516230)

Not to mention you'll find plenty of MySQL DBAs with large multimaster deployments who swear calling it "replication", let alone multimaster replication generous even when everything is working correctly.

It would be nice for PostgreSQL to have an out of the box multimaster solution but those who claim MySQL is replication panacea and PostgreSQL has nothing to offer is only highlighting their ignorance. Slony is consistently used on very large datasets where ACID actually matters. We're talking about two completely different use cases here as far too often, MySQL users are more than happy to wave ACID.

I completely agree with you. While Slony isn't an "out of the box" replication solution, it is a very strong offering.

Re:Built-in replication (0)

Anonymous Coward | more than 4 years ago | (#32515874)

Postgres has had replication for a long time. What it has not had is supported, easy, performant and integrated replication. Quite frankly, I would rather poke my eyes out with an ice pick than ever use Slony again.

Re:Built-in replication (1)

ducomputergeek (595742) | more than 4 years ago | (#32514572)

I don't think "easy" means what you think it means. Better term would be "native" replication support vs 3rd party tools. Yes MySQL does replication out of the box. PostgreSQL had a number of 3rd party tools, each with a slightly different goal in mind. So you had to know which one best suited your purpose whether you were going for HA or load balancing. Where I've seen MySQL fall down has been true HA clustering. Before MySQL 5.1, if the master node went down, you had to bring down the entire cluster and restart it. That could take upwards of 15 - 20 minutes or more on any database of size.

We use PostgreSQL as our database with our Point of Sale application and I've been looking forward to the Warm Standby feature. Most of our locations run 2+ POS terminals. Warm standby would be nice since then we can install the database server on each machine set up for replication. One goes down, the other one takes over, we get notified at technical support, go in after hours remotely and fix the the database that crashed. That being said, we've yet to have PostgreSQL crash in production that was not the result of a hardware failure. (Blown power supply.).

Re:Built-in replication (1)

Ash Vince (602485) | more than 4 years ago | (#32515204)

Before MySQL 5.1, if the master node went down, you had to bring down the entire cluster and restart it. That could take upwards of 15 - 20 minutes or more on any database of size.

Only if you wanted to keep the same master as before. The trick was to let the slave that failed over into being the new master stay that way permanently and then concentrate on bringing the the old master up as a slave.

other then features... (2, Insightful)

jellomizer (103300) | more than 4 years ago | (#32513284)

What I would love to see is some standardization for SQL languages. It would be nice to take an App say say in PostgreSQL then use it in Oracle if you find that you need to go to a bigger infrastructure... As well move down, as a lot of apps are running on DB servers that are too big for their use. While the language has some nice features it would be much better to have an updated set of common function and calls so you can make your SQL more cross platform. A lot of the real work behind SQL isn't much in the Language but in what is happening underneath.

 

Re:other then features... (1)

GooberToo (74388) | more than 4 years ago | (#32513358)

What I would love to see is some standardization for SQL languages.

There is a standardization. PostgreSQL is one of the few RDBMs which actually attempt to follow it. Just the same, "compatibility kits" have been created by third parties to allow for improved MySQL and even Oracle migrations to PostgreSQL. I don't know how well they work or how comprehensive the coverage.

Re:other then features... (4, Informative)

schmiddy (599730) | more than 4 years ago | (#32513682)

You're basically describing the SQL language itself (PostgreSQL does a good job of implementing most of the various SQL standards up to SQL-92 and even SQL-99). Of course, add-on procedural languages like Oracle's PL/SQL aren't going to be supported as-is anytime soon on PostgreSQL, or anywhere else. And of course, each database vendor has their own extensions to the SQL language itself, which other vendors aren't always keen to copy (think MySQL's INSERT ... ON DUPLICATE KEY UPDATE, or PostgreSQL's CLUSTER).

If you're designing a database application which you want to be easily portable across various SQL databases, just try to keep any non-standard-SQL use to a minimum and use of procedural languages simple and only when necessary. Books by Joe Celko stress this ideology, though my take is that it's just about impossible to really get the most out of your database unless you really make use of its extensions, which are there for a reason. For example, Celko discourages the use of auto-increment columns (serial type in Postgres, auto-increment primary key in MySQL), in favor of manually incrementing your sequence using MAX(pkey_column) or similar, which strikes me as absurd and non-scalable.

Re:other then features... (2, Informative)

DragonWriter (970822) | more than 4 years ago | (#32514554)

For example, Celko discourages the use of auto-increment columns (serial type in Postgres, auto-increment primary key in MySQL), in favor of manually incrementing your sequence using MAX(pkey_column) or similar, which strikes me as absurd and non-scalable.

Actually, while ISTR that Celko notes that using non-standard autoincrementing columns is non-portable and that you have to use other ways of doing so if you want code that is usable across different SQL backends, I'm pretty sure that he actually spends quite some time railing against the entire idea of using autoincremented counters, particularly in their common use as automagical keys which are then exposed to the end-user, and advocates, instead, constructing safe exposed identifiers with features like check digits in such use cases.

I don't think there is any case in which Celko argues that an autoincrementing counter column is the right solution to a problem; the non-portability of the common features for these is, for him, one more stroke against using them, but not the main problem.

Re:other then features... (1)

butlerm (3112) | more than 4 years ago | (#32514798)

Auto-increment columns are a really bad idea unless your database guarantees that the same value will never be used twice. Otherwise you should use sequences, which are fast and which both Oracle and PostgreSQL support. Oracle invented the idea, PostgreSQL adopted it.

Re:other then features... (2, Informative)

XanC (644172) | more than 4 years ago | (#32515486)

I've never heard of one that doesn't make that guarantee. MySQL's certainly does.

Re:other then features... (1)

rachit (163465) | more than 4 years ago | (#32515774)

Oracle sequences don't. If you wrap around and use CYCLE in your sequences, it can re-use the same number.

With large enough ID spaces (UUIDs, even just plain 64-bit), this may not be an issue, depending on your app.

Re:other then features... (1)

butlerm (3112) | more than 4 years ago | (#32516350)

Oracle most certainly does guarantee that the values are unique, unless you tell it not to. Unless you need more than 10^38 unique values, Oracle has no problem at all.

Re:other then features... (1)

butlerm (3112) | more than 4 years ago | (#32516202)

Microsoft Access doesn't. The problem is you delete a row and Access re-allocates a number that has previously been used, because it is not present in the table.

Re:other then features... (3, Informative)

butlerm (3112) | more than 4 years ago | (#32516396)

Actually, MySQL doesn't. At least not with InnoDB [mysql.com] :

"InnoDB uses the following algorithm to initialize the auto-increment counter for a table t that contains an AUTO_INCREMENT column named ai_col: After a server startup, for the first insert into a table t, InnoDB executes the equivalent of this statement:

SELECT MAX(ai_col) FROM t FOR UPDATE;

InnoDB increments by one the value retrieved by the statement and assigns it to the column and to the auto-increment counter for the table. If the table is empty, InnoDB uses the value 1"

Re:other then features... (1)

XanC (644172) | more than 4 years ago | (#32516478)

Mercy. That's really dumb. MyISAM tables store the auto increment value on the disk, so you have to go way out of your way to reset it. Otherwise it won't ever repeat.

Thanks for pointing this out. I've been looking at switching to InnoDB, there's one more reason not to...

Re:other then features... (1)

butlerm (3112) | more than 4 years ago | (#32516504)

MySQL has sequences these days, does it not?

Re:other then features... (2, Informative)

MobyDisk (75490) | more than 4 years ago | (#32515706)

add-on procedural languages like Oracle's PL/SQL aren't going to be supported as-is anytime soon on PostgreSQL

Actually, PostgreSQL ships with PL/PGSQL which is pretty-much a clone of PL/SQL.

Re:other then features... (1)

skeptical_monster (1436977) | more than 4 years ago | (#32514056)

What I would love to see is some standardization for SQL languages.

That sounds great! I would love to see every child with their own flying pony. Use an abstraction layer.

Re:other then features... (2, Informative)

Kjella (173770) | more than 4 years ago | (#32514058)

They have tried [wikipedia.org] . But the databases evolved so much faster than the language specification, especially when it comes to anything past plain SQL like triggers. Hell, even such a thing as automatic numbering is done differently in almost every database. Some things they just don't *want* to implement on ideological reasons, like "UPDATE OR INSERT" or "CREATE IF NOT EXISTS" in PostgreSQL at least. PostgreSQL is definitely on the better side of that though, Oracle is pretty much last so I don't know what to tell you, it'll never happen. It's more likely PostgreSQL will grow into an Oracle than that Oracle will ever support the standards as well as PostgreSQL does. By the way, one thing I've noticed with them is that they're very clear on pointing out what they don't support of the standard or if they do anything extra compared to the standard, that's *very* nice even if it's likely unportable anyway...

Re:other then features... (3, Informative)

schmiddy (599730) | more than 4 years ago | (#32514364)

Some things they just don't *want* to implement on ideological reasons, like "UPDATE OR INSERT" or "CREATE IF NOT EXISTS" in PostgreSQL at least.

Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here [postgresql.org] :

And work on MERGE support is itself blocked behind the fact that PostgreSQL doesn't have a good way to lock access to a key value that doesn't exist yet--what other databases call key range locking. See the notes for "Add SQL-standard MERGE/REPLACE/UPSERT command" at http://wiki.postgresql.org/wiki/Todo [postgresql.org] for more information.

Your gripe about CREATE ... IF NOT EXISTS might hold water, depending on what exactly you're complaining about (CREATE TABLE? Or for indexes/constraints?). There does seem to be some resistance [postgresql.org] to CINE, though from what I can tell it's mostly because people would rather have CREATE OR REPLACE, but COR is much harder to implement (what do you do when the object already exists, but is slightly different than the one you're trying to create)?

Re:other then features... (1)

Kjella (173770) | more than 4 years ago | (#32514980)

Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here:

On more research, yes that seems to be my bad. It was probably a very borked implementation attempt I read the discussion of, the subtle difference between "NO WAY" and "NOT *THIS* WAY" was lost at that point I guess.

Re:other then features... (4, Informative)

MobyDisk (75490) | more than 4 years ago | (#32515658)

Postgres actually does this... almost.

First, unlike other SQL engines Postgres is language-independent. There is a plug-in system, and it already ships with a few different SQL variants.

Second, the primary language is PL/PGSQL which is a clone of Oracle's PL/SQL. As a whole, Postgres started as an open-source Oracle clone. If you do a Google search, you will find several success stories of OraclePostgreSQL migrations because the stored procedure language is so similar.

However, you are correct: there needs to be a standard. I see that someone posted and said "SQL is the standard" but that isn't good enough. Raw SQL doesn't provide control structures. There's no loops, no if-then-else, etc. As a whole, I like to avoid those, but they are inevitable.

Related Tangent (3, Informative)

geoffrobinson (109879) | more than 4 years ago | (#32513554)

There's a new open-source database from one of the founders of PostgreSQL (Michael Stonebreaker): http://www.voltdb.com/ [voltdb.com]

I believe it is based on the H-Store project from MIT, and if it is anything like Stonebreaker's Vertica, should be similar in language and syntax to PostgreSQL.

VoltDB should be for high-demand OLTP. It keeps everything in memory and is MPP (not to mention full-ACID compliance). It runs POSIX compliant unixes, even Mac OS 10.5 and later, Linux, etc. They only support CentOS (which is RHEL if memory serves).

Anyway, if anyone is interested in PostgreSQL, I would take a look at this.

Re:Related Tangent (3, Informative)

bill_mcgonigle (4333) | more than 4 years ago | (#32513990)

Anyway, if anyone is interested in PostgreSQL, I would take a look at this.

They don't really have similar use cases, but if you need a tight in-memory ACID database Volt might be just the thing. I think if you've ever been tempted to run sqlite on a ram disk, Volt is your baby. If you need high performance ACID and can afford lots of RAM, Volt probably makes you really happy.

Re:Related Tangent (1)

geoffrobinson (109879) | more than 4 years ago | (#32514674)

Well, yes, different use cases. But that's the one thing I've been noticing about Michael Stonebreaker. He seems to have different project for different needs.

Re:Related Tangent (1)

DragonWriter (970822) | more than 4 years ago | (#32514578)

It runs POSIX compliant unixes, even Mac OS 10.5 and later, Linux, etc.

Huh. And most databases don't run any operating system, much less such a wide variety. But, really, is that a feature people look for in a DBMS?

Re:Related Tangent (1)

geoffrobinson (109879) | more than 4 years ago | (#32515628)

I forgot the word "on."

I like.... (1)

pdxp (1213906) | more than 4 years ago | (#32513558)

the join removal. But what about the partitioning features that have been on the table for quite some time now? The scaffolding is already there, but implementing partitioning is still quite a chore. I just want to be able to gracefully create/manage partitions as in Oracle. There are also a few papers floating around out there with proof-of-concept parallelization/optimization schemes that can be applied with partitioning knowledge.

Re:I like.... (2, Informative)

0racle (667029) | more than 4 years ago | (#32515690)

It got pushed off until later when the decision to integrate streaming replication in this release was made.

I'd say something, but someone will freak out (3, Interesting)

Rallias Ubernerd (1760460) | more than 4 years ago | (#32513798)

I don't understand. What is the advantage of PostgreSQL verses MySQL or a seperate HTTP server?

Forget it. I know someone is going to freak out and mod me troll. I do not intend to cause harm.

Re:I'd say something, but someone will freak out (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32513876)

It's not tainted by the GPL or Monty Wideanus's whining.

Re:I'd say something, but someone will freak out (1)

h4rr4r (612664) | more than 4 years ago | (#32513904)

What does an HTTP server have to do with a DB?

PostgreSQL has a lot of more enterprisy features than MySQL.

Re:I'd say something, but someone will freak out (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#32514492)

ummm restful data services? Besides forget all of that PostgreSQL is a joke of database kept alive by a fringe cult-like following.

Re:I'd say something, but someone will freak out (0)

Anonymous Coward | more than 4 years ago | (#32515818)

That's MySQL.

Re:I'd say something, but someone will freak out (1)

Sxooter (29722) | more than 4 years ago | (#32516370)

Yeah, nobody uses it for anything useful or anything.

Except skype.
And Afilias (the guys what run the .org and .info tlds)
And Cisco.
And the USGS.

Re:I'd say something, but someone will freak out (2, Funny)

Slashdot Parent (995749) | more than 4 years ago | (#32515460)

What does an HTTP server have to do with a DB?

PostgreSQL has a lot of more enterprisy features than MySQL.

You mean like clustering [mysql.com] ?

Oh, wait...

Re:I'd say something, but someone will freak out (1)

Sxooter (29722) | more than 4 years ago | (#32516358)

Wait, is that really a released, supported, and ready for production version? I thought mysql was still working on getting 6.x out the door. Cool if it is.

Re:I'd say something, but someone will freak out (1)

Slashdot Parent (995749) | more than 4 years ago | (#32516452)

Wait, is that really a released, supported, and ready for production version? I thought mysql was still working on getting 6.x out the door. Cool if it is.

FYI, the version # of MySQL Cluster does not track with the version of the DBMS.

Re:I'd say something, but someone will freak out (4, Informative)

coolgeek (140561) | more than 4 years ago | (#32513958)

It's a real database with ACID compliance designed in from the start, not as an afterthought.

Re:I'd say something, but someone will freak out (2, Funny)

Yvan256 (722131) | more than 4 years ago | (#32514030)

If you want to freak out people, you say something like this:

I don't use any database, I use plain XML text files.

Re:I'd say something, but someone will freak out (1)

The MAZZTer (911996) | more than 4 years ago | (#32514292)

Database? XML? CSV has always worked fine for me!

Re:I'd say something, but someone will freak out (3, Funny)

hardburn (141468) | more than 4 years ago | (#32514586)

CSV? I have a team of slaves move stones around a field like a giant abacus.

Re:I'd say something, but someone will freak out (5, Funny)

Anonymous Coward | more than 4 years ago | (#32515894)

And I've been using Google Maps' satellite view to steal all your data. pwned!

Re:I'd say something, but someone will freak out (1)

theskipper (461997) | more than 4 years ago | (#32515370)

on Windows.

Re:I'd say something, but someone will freak out (1)

shutdown -p now (807394) | more than 4 years ago | (#32515780)

I don't use any database, I use plain XML text files.

I use EBCDIC punch cards, you insensitive clod!

Do you know the verb "to google"? (1)

mangu (126918) | more than 4 years ago | (#32514474)

Google [google.com] is your friend.

Re:I'd say something, but someone will freak out (0)

Anonymous Coward | more than 4 years ago | (#32514662)

I don't understand. What is the advantage of PostgreSQL verses MySQL or a seperate HTTP server?

Forget it. I know someone is going to freak out and mod me troll. I do not intend to cause harm.

Why do you assume that MySQL is the default and that anything else must have an "advantage"? (Postgres has many advantages, of course, but that's beside the point.)

Re:I'd say something, but someone will freak out (1)

Slashdot Parent (995749) | more than 4 years ago | (#32515436)

I don't understand. What is the advantage of PostgreSQL verses MySQL or a seperate HTTP server?

Forget it. I know someone is going to freak out and mod me troll. I do not intend to cause harm.

For your sake, I hope that was a troll.

By the way, what's the advantage of a car versus a truck, or a separate gas station?

Re:I'd say something, but someone will freak out (1)

jdoverholt (1229898) | more than 4 years ago | (#32515482)

Straight answer from a friendly DBA: each has its advantages and appropriate applications. Neither has anything to do with HTTP, totally different game. They're both in common use, they both support a good deal of the SQL standard language features (though Postgres is better there), and each has its own extensions to the standard. Just like any other topic here, each has its respective group of fans who will tout its "betterness" and maybe flame you for thinking anything otherwise (see anon response #32513876 [slashdot.org] above). This extends outside the open source world to Microsoft SQL Server and Oracle, too.

Why have two? Well, competition drives innovation, so think of it as a good thing.

Re:I'd say something, but someone will freak out (1)

DragonWriter (970822) | more than 4 years ago | (#32516474)

I don't understand. What is the advantage of PostgreSQL verses MySQL

There are a number of advantages of PostgreSQL versus (not "verses") MySQL: the robust query-rewrite rule engine, better SQL-standard compliance in many areas, support for CTEs with the WITH... and WITH...RECURSIVE constructs, etc., native geometric types, better support for user-defined types and operators (which 9.0 exclusion constraints will make a bigger advantage), the mature GIS add-on, etc.

There are also some advantages to MySQL over PostgreSQL; installation and administration, I think, are still simpler for MySQL (though the last several version of PostgreSQL have closed that gap a lot), and there are probably more introductory resources and prepackaged solutions that target MySQL for lots of common use cases.

or a seperate HTTP server?

Uh, what? The advantage of PostgreSQL vs. an HTTP server? That's like asking what the advantage of a Ferrari is vs. a banana plantation. They aren't alternatives to each other.

Still waiting (2)

coolgeek (140561) | more than 4 years ago | (#32513976)

For the multi-master replication that was promised for 8.4.

Re:Still waiting (2, Informative)

schmiddy (599730) | more than 4 years ago | (#32514456)

Eh? When was multi-master replication ever promised in core? You're probably thinking about hot standby -- the Streaming Replication/Hot Standby code which is the "killer feature" of 9.0 was originally slated for 8.4, but didn't make it in time. I'm really surprised there aren't more comments about SR/HS, as it's an awesome feature which lets Postgres compete with the big boys like Oracle.

Imagine having your expensive database server be dedicated *only* to writes, and having all your read-only queries spread across one or more slave(s) which are also your backup servers. Pretty cool, huh?

Re:Still waiting (2, Interesting)

cxreg (44671) | more than 4 years ago | (#32515284)

and now there's Postgres-XC, which looks very promising

Re:Still waiting (1)

Slashdot Parent (995749) | more than 4 years ago | (#32515514)

I'm really surprised there aren't more comments about SR/HS, as it's an awesome feature which lets Postgres compete with the big boys like Oracle.

Um, no.

Imagine having your expensive database server be dedicated *only* to writes, and having all your read-only queries spread across one or more slave(s) which are also your backup servers. Pretty cool, huh?

And those queries return incorrect results when they are behind the master. Pretty cool, huh?

This is why Postgres/MySQL replication is not even remotely the same thing as Oracle RAC.

Re:Still waiting (0)

Anonymous Coward | more than 4 years ago | (#32515028)

I don't recall multi-master ever being promised as part of the core database. The hot standby we're talking about now was promised and slipped.

Postgresql core will probably not get a multi-master replication system until someone figures out how to do it for real (ie not MySQL's asynchronous multi-master). This isn't an easy question to answer. If DB2 is down, should DB1 stop accepting data? Should it switch back to asynchronous? Should your answers to these questions be forced on everyone else?

kfuck!! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32514752)

DOG THAT It IS. IT when iDC recently

Re:kfuck!! (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32515184)

BSD?

Re:kfuck!! (0)

Anonymous Coward | more than 4 years ago | (#32516136)

Sup dawg! I herd you liek SQL databases so we put a MySQL in your Postgres so you can Insert while you Insertin'!

when they have a tool like phpmyadmin (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32514764)

then they will get used hard core by all the dweebs. Until then enjoy obscurity.

Re:when they have a tool like phpmyadmin (2, Informative)

h4rr4r (612664) | more than 4 years ago | (#32515058)

Phppgadmin is pretty much that, there is also pgadmin which is a desktop app.

I suggest you educate yourself before making such statements.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?