Josh Berkus <[EMAIL PROTECTED]> writes:
> For one thing, this is false optimization; a NULL isn't saving you any table 
> size on an INT or BIGINT column.    NULLs are only smaller on variable-width 
> columns.

Uh ... not true.  The column will not be stored, either way.  Now if you
had a row that otherwise had no nulls, the first null in the column will
cause a null-columns-bitmap to be added, which might more than eat up
the savings from storing a single int or bigint.  But after the first
null, each additional null in a row is a win, free-and-clear, whether
it's fixed-width or not.

(There are also some alignment considerations that might cause the
savings to vanish.)

> More importantly, you should never, ever allow null FKs on a star-topology 
> database.  LEFT OUTER JOINs are vastly less efficient than INNER JOINs in a 
> query, and the difference between having 20 outer joins for your data view, 
> vs 20 regular joins, can easily be a difference of 100x in execution time.

It's not so much that they are necessarily inefficient as that they
constrain the planner's freedom of action.  You need to think a lot more
carefully about the order of joining than when you use inner joins.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to