Skip site navigation (1) Skip section navigation (2)

Re: Inefficient query plan

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: Grzegorz Ja*kiewicz <gryzman(at)gmail(dot)com>
Cc: <roederja(at)ethz(dot)ch>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Inefficient query plan
Date: 2010-08-23 15:03:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Grzegorz Jaœkiewicz<gryzman(at)gmail(dot)com> wrote:
> So, don't narrow down to one solution because it worked for you.
> Keep an open book.
What I was trying to do was advise on what would most directly fix
the problem.  Adding surrogate keys goes way beyond adding the
columns and using them as keys, as I'm sure you're aware if you've
done this on a large scale.  I wouldn't tell someone not to ever use
them; I would advise not to try them when there is a natural key
unless there are problems which are not solved without them, as
appears to have been the case with your database.
I may be a little bit over-sensitive on the topic, because I've seen
so many people who consider it "wrong" to use natural keys on any
table *ever*.  About one out of every four or five programmers who
gets hired here feels compelled to argue that we should add
surrogate keys to all our tables for no reason beyond "it's the
thing to do".  I've been at this for 38 years, most of that as a
consultant to a wide variety of businesses, government agencies, and
NPOs; and in my experience it usually is *not* the right thing to
Don't worry -- when I see evidence that surrogate keys will solve a
problem which has not yielded to more conservative solutions, I'll
suggest using them.

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2010-08-23 15:20:55
Subject: Re: Inefficient query plan
Previous:From: Grzegorz JaśkiewiczDate: 2010-08-23 14:41:01
Subject: Re: Inefficient query plan

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group