Re: Optimizer not using index on 120M row table - Mailing list pgsql-general

From Tom Lane
Subject Re: Optimizer not using index on 120M row table
Date
Msg-id 24477.1049777187@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimizer not using index on 120M row table  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-general
"Jim C. Nasby" <jim@nasby.net> writes:
> ... Next question... will pgsql intelligently
> order things in an item record so that they're stored most efficiently?

No, it stores 'em in the order they're declared in.  There has been some
speculation in the past about trying to be smarter, but I think that
line of thought is pretty much dead in the face of ALTER TABLE ADD/DROP
COLUMN.

> What other things should be considered for column ordering?

There is some execution-speed advantage to putting fixed-width
never-null columns first, then fixed-width nullable columns (in order of
increasing probability of being null, if you want to get really tense),
finally the variable-width columns (nullability no longer matters).
Note that CHAR(n) is considered variable-width, likewise BIT(n) and
NUMERIC(n), even though one might think they could be considered fixed
width.

            regards, tom lane


pgsql-general by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Optimizer not using index on 120M row table
Next
From: Joe Conway
Date:
Subject: Re: Arrays ... need clarification....