-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/07 07:28, Chander Ganesan wrote: > Ron Johnson wrote: >> >> On 01/08/07 20:39, Tom Lane wrote: >> >>> John Sales <spelunker334@xxxxxxxxx> writes: >>> >>>> By doing this, I'm hoping that the query optimizer is smart >>>> enough to see that if a query comes in and requests only the >>>> six columns (that are in the narrower table) that PostgreSQL >>>> won't have to load the wider table into the buffer pool, and >>>> thereby actually have to only access about 10% the amount of >>>> disk that it presently does. >>>> Is this a sound theory? >>>> >>> No. It still has to touch the second table to confirm the >>> existence of rows to join to. >>> >> >> But if a query /requests *only* the six columns (that are in the >> narrower table)/, why will the optimizer care about the other 224 >> columns? >> > It would. A query that uses an inner join implies that a matching entry > must exist in both tables - so the join must occur, otherwise you could > be returning rows that don't satisfy the join condition. Sure, if you were selecting those 6 columns from the "inner join view". <pause> Ah, now that I reread the OP, I see that that's what he seems to mean. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFo5tdS9HxQb37XmcRApwEAKDiqD86q3sh5eePFrgH3+o4LbTAYwCg1Oys 3/WT7eJvbxfE4RDY3E99NAo= =ix6x -----END PGP SIGNATURE-----
