PostgreSQL 9.2: Full-throttle Database

http://www.pgcon.org/2012/schedule/attachments/230_92_grand_prix.pdf

by mace • 14 years ago

148 32 14 years ago

ceyhunkazel3• 14 years ago

Although PostgreSQL is featured database enterprises still using mainly SQL Server or Oracle. http://blog.protegra.com/2012/06/22/sql-server-2012-cheaper-... What can we do for wider adoptation of PostgreSQL?

jerryji• 14 years ago

Get more billion-dollar companies to use PostgreSQL. How? Use PostgreSQL in our own startup, and build it into another billion-dollar company.

ceyhunkazel3• 14 years ago

These will be web startups. Main problem for enterprises is lack of support from enterprise applications (ERP,CRM..) like SAP.

jasonwatkinspdx• 14 years ago

What a fantastic example of false quantification and pretension to objectivity.

ceyhunkazel3• 14 years ago

We need objective comparisons to promote PostgreSQL.

AlisdairO• 14 years ago

Yeesh, you're right, that's pretty bad. The assumption that the customer isn't going to need to update the database version (and thus shell out more...) in those 10 years invalidates the cost assumptions all on its own.

There's legitimate reasons to buy from the big three DB providers: there's a shortage of quality DBAs for postgres, and of course there are the 5-10% of cases that actually need the features/performance of the big 3. Evaluations like this, however, do not make a good case.

Hoff• 14 years ago

Wider adoption? In enterprise-scale companies?

For starters, acquire the reputation for providing high-touch, enterprise-grade, enterprise-focused, enterprise-costs support, with all that entails, and preferably with a cost somewhat below what Oracle charges.

Provide enterprise-friendly DBA training, certifications, and other related materials.

Have your sales reps schmooze the C-level office, and the IT leadership.

But adoption of databases in enterprises in general? They're loathe to change their databases, and have massive investments in their existing software and hardware processes, and their staff and training. The costs involved here are staggering.

If you're looking for more organic growth (and as some of those smaller companies grow and get bigger), that'll happen. But it'll take years. Maybe some acceptance in smaller projects in enterprises, but this sort of "shadow IT" can be a guerrilla effort in an enterprise; discouraged by management.

luriel• 14 years ago

> enterprise-costs support, with all that entails, [...] Provide enterprise-friendly DBA training, certifications, and other related materials.

Most of those things are basically a scam (and often also a racket).

> Have your sales reps schmooze the C-level office, and the IT leadership.

And there you got your answer: basically, bribery.

sandGorgon2• 14 years ago

The simple answer is to make better tools. There is still no single, awesome, dedicated tool to migrate from MySQL to Postgresql. (side note: Did you know that Postgres can actually act as a replication slave for SQL Server ? ).

Again, there is no official Mysql Workbench for Postgres, let alone things like SequelPro. (although a member on the Indian HN - Hackerstreet - is building one at http://pgxplorer.com/)

Second - documentation as compared to other database vendors. No, this is not flamebait - by itself, it is very good and adequate. But for people used to MySQL, SQL Server - it feels...scary.

Check out http://dev.mysql.com/doc/ (sidenote: has docs in epub format as well) vs http://www.postgresql.org/docs/

jeltz3• 14 years ago

> Second - documentation as compared to other database vendors. No, this is not flamebait - by itself, it is very good and adequate. But for people used to MySQL, SQL Server - it feels...scary.

What is scary about it? Genuinely curious since I started out with MySQL and then when I started using PostgreSQL thought the PostgreSQL documentation was the best ever. It probably is a matter of preference, but I am curios what is scary.

EDIT: As for your two links the MySQL page is way scarier.. So many options, so many links.

fdr3• 14 years ago

I basically agree with you, except in regard to documentation, of which I find exceptional in PostgreSQL, even compared to other database systems.

Your toplevel comparison of the index of both manuals is not very informative to me. What do you feel is missing from PostgreSQL's manual that you find in other documentation sources?

j-kidd• 14 years ago

Personally, I found that SQL Server documentation was written to tick the checkbox of "100% documentation coverage", while PostgreSQL documentation was written for human to find useful information.

jeltz3• 14 years ago

The presentation in the article you link to is highly biased in favor for SQL Server. it tells us that "From a cost perspective, SQL Server is the clear winner." which is untrue since PostgreSQL supported by EnterpriseDB, SQL Server and Sybase all have so close TCOs that any minor tweaking of the assumptions could make any of them the winner.

For costs the article really only shows one thing: Oracle is way more expensive than the rest.

For the scoring model the article just asks us to trust in them since they do not provide the results of the feature scoring method.

beggi• 14 years ago

Does anyone have accompanying video of the talk?

mrweasel• 14 years ago

http://www.justin.tv/sfpug/b/331890663

sitharus3• 14 years ago

If my experience with other DBMS (mostly SQL Server) is anything to go by, index only scans will do wonders for append-mostly workloads, and the new transactional scaling looks really good.

I can't wait to try this out, alas I use debian so it's a couple of years out :/

Also my inner grand prix follower is slightly irked by the varying years of the graphics.

elktea• 14 years ago

I'm sure it will end up in back-ports soon.

alternize• 14 years ago

there's an official postgres debian repository now which has the latest versions: http://pgapt.debian.net/

sitharus3• 14 years ago

Thanks, I have no idea how I didn't find that.

photon137• 14 years ago

> index only scans will do wonders for append-mostly workloads

Won't updates be actually slower once indexes are added to take advantage of index-only scans?

Another issue that I can see comes not from having the index-only scan feature (which is cool, though belated) but having a query planner intelligent enough to figure out which index to hit - ie query optimization.

If the columns used in WHERE clause do not contain the appropriate columns (particularly for non-clustered indexes), shouldn't index hints be supported to help pick up the relevant index or would we end up with horrible execution plans leading to tablescans?([1] - I see this as a case of devs overriding users)

[1] http://it.toolbox.com/blogs/database-soup/why-postgresql-doe...

DrJokepu• 14 years ago

This is a horribly naive theory (I have no idea what I'm talking about) but if you have foreign keys you need to get those indexed anyway (otherwise inserts or updates will need to do a sequential scan), and with index-only scans, if the referenced key exists in the index, the tuple won't have to be visited, hence inserts and updates getting faster in tables with foreign keys?

sitharus3• 14 years ago

Yes, updates will be slower if you add more indexes, but if you're doing significantly more reads than writes then it's not much of an issue.

Also Postgres' query planner has been pretty smart about indexes for a long time, and its index format is pretty good as well. For example, if you have table (a, b, c) and index (b, c) Postgres can use the index to filter c by itself, which SQL Server certainly can't.

This is normally because indexes are sorted and hierarchical b-trees - it's ordered by b then c, so c is not ordered. However, a since the index could be smaller than the table itself it might be faster to scan every record of the index than the table.

Postgres' query planner is a thing of wonder.

jeffdavis• 14 years ago

"shouldn't index hints be supported"

Index hints already are supported in multiple different ways:

http://thoughts.davisjeff.com/2011/02/05/why-postgresql-alre...

"I see this as a case of devs overriding users"

I don't think that's an accurate characterization. I'm sure there are some improvements to hinting that would be approved if they are well thought out and don't introduce major maintainability concerns, etc. Someone just needs to do the work required, including considering many alternative approaches which may be radically different from what you typically think of as hints.

The proposals that tend to fail are ones that follow an argument pattern like "Oracle does it this way... therefore it is good... therefore postgres should do something similar".

I'm not trying to dismiss your point at all. I think it's important that postgres give users as much power as possible, and a part of that is having some control over the optimizer without waiting for a new release. Postgres offers that in some innovative ways, but it could do better.

jeltz3• 14 years ago

It is already in Debian experimental and as alternize said there is an official Debian repo ran by the PostgreSQL project.

http://packages.debian.org/experimental/postgresql-9.2

wolfeidau• 14 years ago

Great talk, love the commentary relating the the index contributions by the Russian contributors really impressive work.

Read and write performance improvements are something that will directly improve even current applications.

Talks like this provide valuable insight into what is going on in this amazing project.

craigkerstiens• 14 years ago

Here's the corresponding video to these slides from a separate event that gives an overview of features in 9.2: http://vimeo.com/49337386

PostgreSQL 9.2: Full-throttle Database

Related Stories