[ Informix Logo ] Архив интересных статей по Informix
Пред. по дате ] [ След. по дате ] [ Пред. по нити ] [ След. по нити ][ Индекс по датам ][ Индекс по нитям ]

оЕПЕЯШКЙЮ: can't explain query behavior

From "Shulzhenko Vasyl" <vasilis@softline.kiev.ua>
Date Tue, 2 Feb 1999 11:21:21 +0200


-----хЯУНДМНЕ ЯННАЫЕМХЕ-----
нР: Art S. Kagel <kagel@bloomberg.net>
цПСООШ: comp.databases.informix
йНЛС: Yan Zhu <yan.zhu@infinity-insurance.com>
дЮРЮ: 1 ТЕБПЮКЪ 1999 Ц. 18:45
рЕЛЮ: Re: can't explain query behavior


>Yan Zhu wrote:
>>
>> hi all:
>>     using online 7.23 on solaris 2.6.
>>     here is the table def:
>[SNIP]
>> an update satistics high was done on the whole table, my question is,
>> why in the world did it use sequential scan while there is a composite
>> key covers those two fields?
>
>Because the filter value of the range on acct_date is too low.  What %
>of the rows match that pair of criteria?  The rows are small so there
>are over 90 rows on a data page.  If the engine predicts that more than
>~12% of the rows will match the criteria it will decide that it will
>most likely have to read every page anyway so why waste the I/Os to
>also read index pages?  It is even possible that company is not a good
>filter either.  Perhaps if you had an index on company first then
>acct_date the optimizer might use it.
>
>Art S. Kagel



Home ] Сайт создан при поддержке Украинского представительства Informix Software Inc. Hosted by ANTEC