Как заставить INTERBASE изменить план

← →
den_777 (2005-02-21 16:43) [0]

Проблема в следующем. Предположим есть таблица со следующими полями
field1 integer,
field2 integer,
field3 integer,
field4 varchar(10),
field5 varchar(5),
field6 varchar(2),
field7 varchar(2)

создан индекс
CREATE INDEX IDX1 ON MYTBL(FIElD4,FIElD5,FIElD6,FIElD7);

Выполняется запрос
select distinct FIElD4,FIElD5,FIElD6,FIElD7 from MYTBL
И Intebase 5.6 и FireBird1.5.1 строят один и тот же план:
PLAN (MYTBL NATURAL)
а план подставленный вручную
PLAN ((MYTBL index (IDX1)))
пониматься не хочет.

Это так и заложено в идеологии баз с многоверсионностью записей или просто недоработка INTERBASE, ведь вся информация для моего запроса может быть извлечена из индекса, а INTEBASE никак не хочет этого делать.

← →
Vemer © (2005-02-21 16:47) [1]

forum.ibase.ru
sql.ru

← →
Sergey13 © (2005-02-21 16:52) [2]

2den_777
А какой план ты хотел увидеть для чтения всей таблицы? ИБ вроде не умеет брать инфу из индекса. Хотя может я и ошибаюсь.

← →
den_777 (2005-02-21 16:59) [3]

> ИБ вроде не умеет брать инфу из индекса

Именно про это я и справшивал. Умеет или нет брать INTERBASE информацию из индекса, а желаемый мною план уже написан выше

Вопрос не случаен, просто когда я работал с INFORMIX, там даже такое понятие в сосавляемом оптимизаторе плане было "INDEX ONLY", т.е когда в запросе перечислены только поля, которые входят в какие либо индексы по этой таблице, то обращение к самой таблице не будет вовсе.

← →
Petr V. Abramov © (2005-02-21 16:59) [4]

> ИБ вроде не умеет брать инфу из индекса.
Умеет. когда это имеет смысл :)

> ведь вся информация для моего запроса может быть извлечена из индекса
Ну что, что может. А с чего ты решил, index full scan будет быстрее table full scan, тем более индекс с таким размером ключа?

← →
den_777 (2005-02-21 17:02) [5]

> Ну что, что может. А с чего ты решил, index full scan будет
> быстрее table full scan, тем более индекс с таким размером
> ключа?

В реальной таблице 54 поля, и я почему-то думаю что index full scan был бы намного быстрее table full scan

← →
Petr V. Abramov © (2005-02-21 17:03) [6]

Ну может, в Informix index full scan оптимизирован.
Хотя в данном конкретном случае, IMHO, какой хитроумный алгоритм не используй, выигрыша сильного не будет.
вот если б размер записи килобайт 100 был, тогда б имело смысл

← →
den_777 (2005-02-21 17:05) [7]

Скажу даже больше. Проэкспериментировал с похожей по струтуре таблицой, но в кторой можно сохдать уникальный индекс по 4 полям. select distinct вроде как сам собой напрашивается на испоьзование уникального индекса по этим полям . Но не тут то было, опять table full scan.

← →
Petr V. Abramov © (2005-02-21 17:06) [8]

> В реальной таблице 54 поля
Ну тогда да.
Но успокойте себя тем, что FB - халявный, а Informix дорого стоит. :)))

← →
Johnmen © (2005-02-21 17:07) [9]

http://www.ibase.ru/mail/distindex.txt
http://www.ibase.ru/ibfaq.htm#distinct

← →
Petr V. Abramov © (2005-02-21 17:10) [10]

> select distinct вроде как сам собой напрашивается на испоьзование уникального индекса по этим полям
если индекс уникальный, зачем distinct ???

← →
den_777 (2005-02-21 17:11) [11]

> Хотя в данном конкретном случае, IMHO, какой хитроумный
> алгоритм не используй, выигрыша сильного не будет

Это почему. Очень даже не очевидно. Любой индекс имеет древовидную структуру. Селективность индекса 0.03. На основе этих двух фактов наверняка можно придумать алгоритм с обходом не всех ветвей и элементов индекса. Это и будет намного быстрее.

← →
Petr V. Abramov © (2005-02-21 17:15) [12]

> наверняка можно придумать алгоритм с обходом не всех ветвей и элементов индекса
Как же это не всех, если нужны все ключи???

← →
Sergey13 © (2005-02-21 17:16) [13]

2[3] den_777 (21.02.05 16:59)
> т.е когда в запросе перечислены только поля, которые входят в какие либо индексы по этой таблице
Ну наверное не "в какие либо", а в индекс учавствующий в запросе.

← →
den_777 (2005-02-21 17:18) [14]

> Johnmen © (21.02.05 17:07) [9]
> http://www.ibase.ru/mail/distindex.txt

So if you want to use an index to select "distinct a, b, c, d", you
should define an index on "a, b, c, d". If you define separate indexes
on each column, InterBase will use only the index on "a".

И в чем отличие от моего варианта.

> http://www.ibase.ru/ibfaq.htm#distinct

В том то и дело, что у меня IB5.6 а использованием индекса и не пахнет

← →
den_777 (2005-02-21 17:19) [15]

> Как же это не всех, если нужны все ключи???

Наверное мы с тобой по разному понимаем как устроен индекс

← →
Johnmen © (2005-02-21 17:28) [16]

>den_777 (21.02.05 17:18) [14]

Весь текст прочитай.

← →
den_777 (2005-02-21 17:48) [17]

> Весь текст прочитай.

Извини. Может я туп или плохо понимаю английский, но перечитав внимательно еще раз, так и не понял на что мне следовало обратить внимание. Если не трудно можно указать конкретную фразу в этой статье, которая объясняет данное поведение INTERBASE, при select distinct по 4 полям и более.
С уважением.

Я не совсем понял, о каком данном поведении речь, но про использование индекса там написано. При этом не важно, что он явно не указан в плане.

← →
den_777 (2005-02-21 17:59) [19]

> Я не совсем понял, о каком данном поведении речь

речь о том что в моем запросе в плане индекс не используется, хотя в статье написано, что если есть комбинированный(составной) индекс по всем полям участвующем в запросе, то этот индекс должен использоваться. Вот это мне и непонятно

поставь Order by и будет тебе использование индекса, вот только зачем?

← →
den_777 (2005-02-21 18:15) [21]

> поставь Order by и будет тебе использование индекса

не будет, уже попробовал

а ты поля в нужном порядке в order ставил, как в индексе?

← →
den_777 (2005-02-21 18:29) [23]

> а ты поля в нужном порядке в order ставил, как в индексе?

а то(ну в смысле конечно), ладно предлагаю закончить дискуссию, потому как мне борльше было нужно не объяснение поведения INTERBASE, а возможный способ ускорения запроса. Как следует из дискусси и доп материалов, такого способа нет(или он мне еще неведом).

Как заставить INTERBASE изменить план Найти похожие ветки