From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Cc: | Gabriele Bartolini <angusgb(at)tin(dot)it>, "Aaron Werman" <awerman2(at)hotmail(dot)com> |
Subject: | Re: Data warehousing requirements |
Date: | 2004-10-07 22:50:20 |
Message-ID: | 200410071550.20665.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Gabriele,
> That's another interesting argument. Again, I had in mind the space
> efficiency principle and I decided to use null IDs for dimension tables if
> I don't have the information. I noticed though that in those cases I can't
> use any index and performances result very poor.
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. If you're going to start counting bytes, make sure it's an informed
count.
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.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Werman | 2004-10-08 01:19:44 | Re: Data warehousing requirements |
Previous Message | Mischa Sandberg | 2004-10-07 20:00:04 | Re: sequential scan on select distinct |