Re: Problems with SELECT *

From: Pablo Sanchez <pablo_at_dev.null>
Date: Fri, 14 Mar 2003 12:40:06 -0600
Message-ID: <Xns933E76B29DEA0pingottpingottbah_at_216.166.71.233>


"Bob Badour" <bbadour_at_golden.net> wrote in news:7Cpca.44$lE4.5312631_at_mantis.golden.net:

> "Pablo Sanchez" <pablo_at_dev.null> wrote in message
> news:Xns933E6690CA881pingottpingottbah_at_216.166.71.233...

>> "Gianluca Hotz" <ghotz_at_alphasys.it> wrote in news:b4skjr$237et0$1_at_ID-
>> 184953.news.dfncis.de:
>>
>> > Another thing is that some system, provided there's an index,
>> > may "cover" the query fetching densely populated index pages
>> > instead of fetching the data pages.
>>
>> It's unwise for application solutions to rely on 'piggybacking' off of
>> indexes.  If you can get away with it, that's great but I wouldn't
>> bank on it, it's too fragile of a solution.

>
> He never recommended that applications rely on this.

Agreed and I wasn't meaning to imply that.

> He suggested that writing applications to explicitly request the
> data they need will sometimes allow this optimization. Using "SELECT
> *" indiscriminately will generally prohibit it.

Yup, that's what I understood. I was still answering in the context of the original poster (imagine that on this NG?! <g>).

A gentle reminder, the original poster was stating the reasons why to avoid 'select *' and putting down the above reason is a good reason but I don't think it's paramount. My vote is to avoid it but primarily because people's times are more expensive than machine.

Thx!

-- 
Pablo Sanchez, High-Performance Database Engineering
http://www.hpdbe.com
Received on Fri Mar 14 2003 - 19:40:06 CET

Original text of this message