Re: Problems with SELECT *
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.comReceived on Fri Mar 14 2003 - 19:40:06 CET