> Its of note that Postgres does not automatically create an index when creating the primary key, it is a separate step which you must do if not using an ORM. (http://postgresguide.com/performance/indexes.html#primary-ke...)

This directly contradicts with what the PostgreSQL documentation says.

> Adding a primary key will automatically create a unique btree index on the column or group of columns used in the primary key. (http://www.postgresql.org/docs/9.1/interactive/ddl-constrain...)

Is there a fundamental difference to the default pkey index versus an explicitly created index?

perhaps he meant a foreign key, not primary key.

postgresql doesn't automatically create indexes for foreign keys.

> Is there a fundamental difference to the default pkey index versus an explicitly created index?

i don't know of any in practice.

You're correct it was intended to be foreign keys, correctly updated now.

I believe the difference would be on the constraint. A primary key is intended to be unique, where as an index does not alway carry that constraint.

A primary key is the same thing as a unique index (any index which enforces unique entries) + a not null constraint.

It might make a difference in the heuristic for finding functional dependencies for group by though. This feature was introduced in 9.1 and allows one to not always have to list all columns in the GROUP BY clause.

They ink to PostgreSQL 9.0 High Performance (http://www.amazon.com/gp/product/184951030X/), which I agree is a great book if you're a sysadmin supporting PostgreSQL.

I have this on my desk right now - it's been extremely helpful in scaling a large database and I'd recommend it to those who don't have any experience with indexing and partitioning as well (it explains them quite clearly). It goes into lots of system settings for tuning as well.

C. J. Date is a very well known technical writer. He has written extensively about SQL and relational theory.

While the idea is nice, please note that the official name is PostgreSQL and Postgres is an accepted alias. "Postgre SQL" is just plain wrong.

It's wrong, but probably unavoidable. Attaching a spoken acronym to the end of a pronounced name is just so bizarre (has anyone else ever done that?) that people will simply skip it.

I've heard people say "post-gre", and like a new English speaker saying "We goed to the park", this overgeneralization isn't at all surprising. In computers, acronyms after names are very common, and it's typically harmless to omit them, e.g., saying "Windows XP" as "Windows" is more generic but not wrong.

I've never heard anybody ever say "post-gres-que-ell". ("Postgres" is correct, unambiguous, and sounds better. Why would I keep going and make it twice as many syllables?) They're trying to fight against the natural process of linguistic clipping with a FAQ!

I love Postgres as a database but I really wish they'd just drop that weird spelling. I don't think it's helping them at all these days.

> I've never heard anybody ever say "post-gres-que-ell".

I frequently, but not exclusively, say it like that. You knew someone would show up to say this. I admit I get weird looks. My coworkers all call it "Postgres."

I think you're right, but I also think if that's the best thing we have to complain about we have it pretty good.

Postgre SQL is admittedly very wrong, however its also perhaps one of the biggest mistakes the project made early on (admitted by various community members).

I'll work to call out the two correct ones, and call out the confusion of the other separately.

"Curated"? As opposed to a what, an automatically generated one?

SELECT RANDOM(GUIDE) FROM DATABASES WHERE DATABASE_NAME = 'POSTGRES'; ?!

The original article, thankfully, says nothing about being "curated".