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]
