-----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 <[EMAIL PROTECTED]> 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-----
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
