Slashdot Mirror
PostgreSQL 8.1 Available
atani writes "PostgreSQL 8.1 has been posted, though not officially announced as of this moment. This release includes two-phased commits, improved SMP and overall performance, a new role system replaces the older user/group, autovacuum is now within the backend rather than a separate contrib module, and various improvements, performance enhancements, and bugfixes. " You can also read the developer notes for the popular database. One thing is clear- with the newest Postresql and MySql, you have much to choose from.
I've tested RC1 with some applications, and was really impressed by the bitmap-indices. I hope to see soon a multi-master replication now that 2PC is available. I've heard Slony-2 will have it.
Found it!
/ is the link.
http://www.postgresql.org/ftp/binary/v8.1.0/win32
Clicking the '8.1' link on the 'new releases' section on the front page takes you to the 'source' files only. That was the problem I had!
creation science book
Been using RC1/RC2 for some time now. I'm impressed with the role feature, although it won't add much to the average user. The speed has been night and day with 7.3. I also haven't had any problems with the RC's in the slightest except one: a renamed table then wouldn't let me delete the sequence it depended on after the renamed table was deleted. Apparently I wasn't the only one who found it and it has been reported as fixed, though who knows.
My only beef with PgSQL has been there since before the 7's. There is still no way to not show the list of databases to users who have no right or access to those databases. Why should userA with rights to databaseA see that there is a databaseB or databaseC? This really seems like a simple feature, yet nobody will accept it into the release.
-M
when you see the word 'Linux', drink!
pgAdmin III bundled tool is 1.4 - I think I was using 1.3 last time I installed. Visually it looks a bit nicer - I'm assuming they've fixed some bugs or something similar to warrant a number change. :)
1.3 was the development series for 1.4, the new stable release as of yesterday. There are a heap of new features over 1.2 (which shipped with PostgreSQL 8.0) - see http://www.postgresql.org/about/news.419 for details.
sqlite is good. But it does require setup.
You still need to use CREATE TABLE, INSERTs and the like.
You need to connect to the thing in your code, with the same attendent problems as other connection strings. sqlite has a poor jdbc element, if java's your gig.
There are a couple of versions of sqlite. Be aware of this. There is sqlite and sqlite3. Note the jump there from 1 straight to 3. You'll need different DBD drivers there in Perl.
Also, there is no multiple write capability, so you have to synchrinise on this yourself. Who do you trust to write code for ACID commits? Yourself or say, the Postgres team?.
Where sqlite rocks is where the data is entirely read only, which eats out Mysqls lunch.
Also remember that sqlite and Postgres are not mutually exclusive.
In my sqlite setup, I deploy a sqlite database as a file for the fast read only webservers. Where is this data drawn from? My Postgres database with perl to generate the file. So you can get the UPDATE integrity of Postgres with the blazing speed and compactness of sqlite. This works where your application has discreet state where everything is consistent and you can batch update your sqlite.
[% slash_sig_val.text %]
Most handle it by giving you the view of the data before the other user started to modify it. The person who is editing's edits do not show until all of the edit is finished.
Postgres docs actually have a chapter on this: Concurrency Control. Like most high-end databases Postgres can handle this situation in different ways, depending on how it is set up...
A database should never tell you that the data is not avalible. It should always give you the best version of the data it has.
'Sensible' is a curse word.
For those who really understand relational database design, there is nothing that object inheritance can represent that you can't handle relationally.
In fact, the PostgreSQL team has been musing for years on whether to drop object inheritance completely, because it just muddies the waters of relational design, and causes implementation details to affect logical design.
But interestingly, table inheritance has become a solution to a lower-level implementation problem: "horizontal" table partitioning. Using inheritance together with tablespaces (available since 8.0), you can break a large table into multiple subtables, each on a different physical storage device, then make a table that inherits from them all to present unified querying to the whole range of data. This is a *big* advantage for very large databases.