From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | "Robert J(dot) Sanford, Jr(dot)" <rsanford(at)nolimitsystems(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: optimizing queries and indexes... |
Date: | 2001-09-10 05:01:11 |
Message-ID: | Pine.BSF.4.21.0109092158420.12944-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Sun, 9 Sep 2001, Josh Berkus wrote:
> Ah. Well, you answer optimization questions so often that I'd assumed
> that you had a hand in it. Is the optimizer all Tom and Bruce's work?
Mostly Tom I believe.
> > At least on 7.1 and below, if you have a dummy value that is very
> > common
> > but doesn't really pass any information (like 'N/A' for example),
> > consider
> > using NULL instead. The optimizer statistics can often be thrown
> > off-kilter by values that are much more common than the real data.
>
> Personally, I cannot reccomend this. There are a number of
> normalization problems with using NULL instead of 'N/A' or 0 or another
> "no" value. Some database theorists (Fabian Pascal & co.) even propose
> the elimination of NULL from the SQL spec on the grounds that it
> encourages bad DB design. As such, I have a hard time reccommending any
> course that involves adding *more* NULLs to the database, especially for
> a marginal query performance gain.
NULLs are rather ugly, but the difference is often index scan vs sequence
scan and on billion row tables that starts being those messages about, I
do this query and it never comes back. This should become much less of an
issue in 7.2 however with Tom's enhancing of the statistics generated.
From | Date | Subject | |
---|---|---|---|
Next Message | jack | 2001-09-10 07:47:35 | array variable in pl/pgsql |
Previous Message | Josh Berkus | 2001-09-10 01:05:12 | Re: optimizing queries and indexes... |