Linked by Eugenia Loli on Wed 6th Dec 2006 00:40 UTC
Databases PostgreSQL 8.2 is now released (sources, binaries) while you can read the release notes here.
Order by: Score:
LDAP Authentication!
by HalcyonBlue on Wed 6th Dec 2006 00:52 UTC
HalcyonBlue
Member since:
2006-12-06

It's great to see the PostgreSQL team continuing to deliver high quality releases with great improvements. While I see many features and performance improvements - this gem in the changelog cought my eye:

"Add native LDAP authentication (Magnus Hagander)

This is particularly useful for platforms that do not support PAM, such as Win32."

LDAP can be a really cool way to keep your users and data in an open and non-proprietary form and tie services and user accounts together across a heterogeneous network. Kudos to the PGSQL team for adding this and a host of other great features!

Reply Score: 5

RE: LDAP Authentication!
by tyrione on Wed 6th Dec 2006 02:48 UTC in reply to "LDAP Authentication!"
tyrione Member since:
2005-11-21

It's also good for platforms like OS X.

Reply Score: 1

Forms and reports
by sbenitezb on Wed 6th Dec 2006 00:58 UTC
sbenitezb
Member since:
2005-07-22

Does someone know if there's some form and report designer for Postgres (linux version)?

Reply Score: 3

RE: Forms and reports
by griffbrad on Wed 6th Dec 2006 01:01 UTC in reply to "Forms and reports"
griffbrad Member since:
2006-04-27
RE: Forms and reports
by FishB8 on Wed 6th Dec 2006 04:06 UTC in reply to "Forms and reports"
FishB8 Member since:
2006-01-16

Rekall. Does forms, reports, and has built in support for python scripts.

Reply Score: 3

PostgreSQL 8.2 Benchmarks
by xhfdc on Wed 6th Dec 2006 01:27 UTC
xhfdc
Member since:
2006-03-16

8.2 performs very well.

http://tweakers.net/reviews/657/6

Reply Score: 1

RE: PostgreSQL 8.2 Benchmarks
by jayson.knight on Wed 6th Dec 2006 06:32 UTC in reply to "PostgreSQL 8.2 Benchmarks"
jayson.knight Member since:
2005-07-06

When they get an entry in the top 10 over on TPC, they'll be taken seriously in the enterprise RDBMS sector.

It's worth mentioning that I'm a huge Postgre fan...for small projects where price is a large factor.

Reply Score: 3

RE[2]: PostgreSQL 8.2 Benchmarks
by ormandj on Wed 6th Dec 2006 08:12 UTC in reply to "RE: PostgreSQL 8.2 Benchmarks"
ormandj Member since:
2005-10-09

Correct me if I'm wrong, but the TPC top ten is nothing more than a money race.

#1 cost nearly $12 million
#10 cost ~$4 million

I other words, unless you feel like donating a huge chunk of money/lots of hardware, you're NOT going to see PostgreSQL on that list. Nor is that list any indicator of performance to expect. Nor does any *smart* company base their purchasing decision on that *obviously* skewed list.

http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=al...

Reply Score: 3

jayson.knight Member since:
2005-07-06

That's the wrong list to look at, the TPC-C Price/Performance list is more accurate for real world scenarios (where price of the overall system is more of a factor):

http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp

The #6 system is a reasonable $27,500, and at ~18,000 transactions/minute is blistering fast for that price point.

The FAQ has more details (http://www.tpc.org/tpcc/faq.asp) and anyone is free to submit their own system for benchmarking. The only skewing factor is this point in the FAQ:

"Second, vendors choose to run benchmarks that provide their customer base with results relevant to those customers. Third, vendors may choose to run one benchmark over another because they believe one gives them better performance or price/performance than another benchmark."

Reply Score: 3

RE[4]: PostgreSQL 8.2 Benchmarks
by carniz on Wed 6th Dec 2006 09:58 UTC in reply to "RE[3]: PostgreSQL 8.2 Benchmarks"
carniz Member since:
2006-12-06

The #6 system is a reasonable $27,500, and at ~18,000 transactions/minute is blistering fast for that price point.

18,000 transactions/minute? It's not that much - our HP DL385 (using a low-end HP MSA1500) clocked 33,059 transactions/minute. This was with EnterpriseDB 8.1, btw. I guess it did cost a little more than $27,000 though..don't recall how much exactly.

Reply Score: 1

RE[4]: PostgreSQL 8.2 Benchmarks
by steve_s on Wed 6th Dec 2006 10:10 UTC in reply to "RE[3]: PostgreSQL 8.2 Benchmarks"
steve_s Member since:
2006-01-16

It should be noted that there are currently no PostgreSQL benchmarks at all on the TPC list.

Reply Score: 3

RE[4]: PostgreSQL 8.2 Benchmarks
by kjn9 on Thu 7th Dec 2006 00:44 UTC in reply to "RE[3]: PostgreSQL 8.2 Benchmarks"
kjn9 Member since:
2006-01-17

The TPC-C benchmark spec, and the full report on one of the benchmarks, make interesting reading.

Taking the Dell PowerEdge at position 2 in the list, the most expensive component, at 53% of the total cost, is the SCSI disk subsystem, with 56 SCSI drives, each 36 Gb, in a RAID 0 configuration. The benchmark spec requires 60 days' data to be stored, so storage is always going to be a major part of the expense. The MS software licenses and support are only 18% of the total cost of the system. The requirement for 3 years 24 x 7 support appears to have been interpreted liberally for the MS software, as "one incident" at $245.

The benchmark is designed for a DB running orders, payments and warehousing for a business - quite a large business, if it is processing tens of thousands of transactions per minute.

Many of us will be interested in a different workload, where ACID and RAID are essential, but a pair of disks will suffice, and writes are much less frequent than reads - as the backend of CMS or web hosting facility, for example.

For such a workload, we really need a different benchmark. The price advantage of PostgreSQL will make a much bigger difference to the final performance/price ratio.

Reply Score: 2

Easier to port from MySQL to Postgresql
by unoengborg on Wed 6th Dec 2006 06:29 UTC
unoengborg
Member since:
2005-07-06

One of the the new features I like the most is the INSERT ... VALUES (...), (...), statment. It will make it easier to move data from MySQL to Postgresql as this is the form that MySQL uses to dump out data to SQL.

To the Postgresql team - Thanks for a great product!

Reply Score: 5

saxiyn Member since:
2005-07-08

One of the the new features I like the most is the INSERT ... VALUES (...), (...), statment. It will make it easier to move data from MySQL to Postgresql as this is the form that MySQL uses to dump out data to SQL.

This is misleading. There are *much* more things to care to convert from MySQL dump to PostgreSQL dump, and running psql on MySQL dump will never be perfect. You need a conversion script anyway.

And there had been a nice conversion script for a long time, namely mysql2pgsql. As one will run mysql2pgsql (or similar) anyway, in the context of migrating dump, it doesn't matter whether new PostgreSQL supports particular MySQL syntax or not.

http://gborg.postgresql.org/project/mysql2psql/projdisplay.php

Reply Score: 1

unoengborg Member since:
2005-07-06

Sorry if you felt mislead, having the new insert statement is of course not everything that is needed.
Neither is the mysql2psql perl script.

You would may also want to add some mysql specific functions to postgresql. You can find such a library at
http://pgfoundry.org/projects/mysqlcompat/

The new insert statement is still valuable to users that not have perl installed (e.g windows users)

Having this new insert statment, will also make it possible to make conversion scripts that runs faster especially for large data sets.

Reply Score: 2

Nice
by mcduck on Wed 6th Dec 2006 06:46 UTC
mcduck
Member since:
2005-11-23

Getting closer and closer to the point of changing from MySQL to PostgreSQL, but not quite there yet.

Reply Score: 1

Wow!
by static666 on Wed 6th Dec 2006 07:59 UTC
static666
Member since:
2006-06-09

A short summary from pgsql-announce:

Among the features of this new version are:
-- Higher performance (+20% on OLTP tests)
-- Improved Warm standby databases
-- Online index builds
-- SQL2003 aggregates
-- Improved TSearch2 with Generalized Inverted Indexes
-- Support for DTrace probes
-- Advisory Locks
-- New ISN/ISBN and pgCrypto modules
-- Selective pg_dump options

... and many more included in the over 300 patches which went into this version.

Reply Score: 2

RE: Wow!
by whartung on Wed 6th Dec 2006 18:16 UTC in reply to "Wow!"
whartung Member since:
2005-07-06

-- Support for DTrace probes

What a great contribution, adding support for DTrace.

This can only make Postgres better, faster, since now they have the system exposed to a tool like DTrace. It will let the folks that run Postgres on Solaris in the wild able to run monitoring scripts when things go bad for better feedback for themselves, and to the Postgres developers.

While DTrace is limited still to Solaris (I think -- no, wait, didn't Apple put it in Leopard??), it will help everyone in the Postgres community long term simply because it lets folks monitor production systems that much easier.

Reply Score: 2

RE[2]: Wow!
by rycamor on Wed 6th Dec 2006 18:25 UTC in reply to "RE: Wow!"
rycamor Member since:
2005-07-18

While DTrace is limited still to Solaris (I think -- no, wait, didn't Apple put it in Leopard??), it will help everyone in the Postgres community long term simply because it lets folks monitor production systems that much easier.

Also available for FreeBSD: http://people.freebsd.org/~jb/dtrace/

Reply Score: 2

RE[2]: Wow!
by captrb on Wed 6th Dec 2006 18:25 UTC in reply to "RE: Wow!"
captrb Member since:
2005-09-16

"(I think -- no, wait, didn't Apple put it in Leopard??)"

I think you are recalling some rumors/evidence that Apple might be porting Sun's ZFS filesystem. There is a DTrace port for FreeBSD in the works.

http://people.freebsd.org/~jb/dtrace/

I'm quite excited about these DTrace probes. I upgraded to Solaris 10 specifically to use DTrace to measure and tune Postgresql. Even without custom probes inside of Postgresql, I was able to correlate high level measurements (queries, simultanious sessions) with very low level measurements (disk head movements as contention, OS filesystem cache hits/misses).

It can't wait to see what is possible now.

Reply Score: 2

RE[3]: Wow!
by nick8325 on Wed 6th Dec 2006 19:34 UTC in reply to "RE[2]: Wow!"
nick8325 Member since:
2005-10-06

It *is* in Leopard, apparently - see http://developer.apple.com/leopard/overview/ (under Xray).

Reply Score: 3

RE[4]: Wow!
by captrb on Wed 6th Dec 2006 22:09 UTC in reply to "RE[3]: Wow!"
captrb Member since:
2005-09-16

"It *is* in Leopard, apparently"

Wow, I'd hadn't heard about that. Dang. I may have to by a Mac one of these days.

Reply Score: 1

Sun's Role...
by kaiwai on Wed 6th Dec 2006 10:45 UTC
kaiwai
Member since:
2005-07-06

With Sun choosing PostgreSQL for their database of choice, is there a 'tracking' on what contributions they've made back? I'm assuming that Sun is investing money into improving its scalability and so forth; is there a roadmap etc?

Reply Score: 2

RE: Sun's Role... (&Benchmarking)
by jberkus on Fri 8th Dec 2006 03:54 UTC in reply to "Sun's Role..."
jberkus Member since:
2006-12-07

As both a member of the PostgreSQL Core Team and Sun PostgreSQL Lead, I think I need to respond to the questions regarding Sun's contributions to PostgreSQL, as well as benchmarking, because the two are related.

Most companies that join the PostgreSQL community take a while to "ramp up" their contributions, and Sun is no exception. However, they do pay my salary and I spend 60% of my time on PostgreSQL PR and performance, so that's a start. Further, in addition to Solaris stuff (DTrace, Sun Cluster, Zones, ZFS, etc.) Sun is also helping me with PostgreSQL benchmarking.

Maybe most people don't know it, but Sun actually has one of the larger and more experienced benchmarking teams in the business. We are already working on TPC and Spec benchmarks, but these things take time -- a lot of time. Expect to see good things in the next year, but don't wait on one foot.

--Josh Berkus

Reply Score: 1

Congratulations
by rekursion on Wed 6th Dec 2006 21:10 UTC
rekursion
Member since:
2006-11-16

I've really looked forward to this new release -- and especially this new feature called hstore. And congratulations to the PostgreSQL developers.

I run this database on several FreeBSD servers, and it certainly performs very well.

Reply Score: 1