Почему не могу явно указать имя индекса?

← →
plans (2003-05-27 13:24) [0]

Трабл при использовании IBManager:
select t1.f1
from table t1
where t1.id = :id
plan (t1 index(IDX_id))

ругается, что нет такого индекса:
fmCompile.trCompile:
Invalid token.
invalid request BLR at offset 132.
there is no index IDX_id for table <table>.
Как правильно указать? Диалект 3. Индекс точно есть.

← →
Alexandr © (2003-05-27 13:34) [1]

да он и сам должен прицепиться.
Зачем тебе план вручную писать для такого простого запроса.

← →
Alexandr © (2003-05-27 13:35) [2]

диалект 3 говоришь...
А чего там, с регистром символов не напутано?

← →
plans (2003-05-27 13:35) [3]

так не прицепляется... natural в плане пишет...

← →
plans (2003-05-27 13:36) [4]

не напутано. уже и кавычки ставил и регистр менял - ни фига.

← →
plans (2003-05-27 13:39) [5]

> Alexandr © (27.05.03 13:34)

я просто хочу на простом убедить почему не могу указать имя индекса. а я оптимизирую большой запрос - там у меня почему-то, если есть FK, то не подхватывает индекс.

← →
plans (2003-05-27 13:52) [6]

VМастаки, омогите не могу догнать что ему надо. не хочет подключать индекс если его яно указать...

← →
Zz_ (2003-05-27 13:59) [7]

IDX_id - это чистый индекс или имя FK?

Если имя FK, то насколько я помню, IB
глубоко ложит на это имя, а использует,
самосозданный индеск RDB$FOREIGNxxx. Его
тогда и надо в плане прописывать. Кажись
аналогично и с PK.

← →
DarkGreen © (2003-05-27 13:59) [8]

Тебе уже Alexandr © (27.05.03 13:35) говорил, ни чего с регистрами не напутано? Посмотри в RDB$INDICES как твой индекс называется

← →
plans (2003-05-27 14:10) [9]

> IDX_id - это чистый индекс или имя FK?

чистый индекс, но по этому полю еще есть и PK.

← →
Zacho © (2003-05-27 14:19) [10]

Не лучше ли разобраться, почему оптимизатор не использует индексы ? Может в данном случае natural действительно быстрее, а конкретное указание плана приведет наоборот, к ухудшению производительности ?

← →
plans (2003-05-27 14:23) [11]

> Zacho © (27.05.03 14:19)
> Не лучше ли разобраться, почему оптимизатор не использует
> индексы ?

как?
я хочу понять почему явное указание индекса не катит?

← →
Danilka © (2003-05-27 14:26) [12]

Zacho © (27.05.03 14:19)
а разве он в этом случае будет ругаться на индекс?

plans
приведи DDL своей таблицы, вместе с реальным запросом.

← →
plans (2003-05-27 14:32) [13]

/* Таблица: employee_working */

CREATE TABLE "employee_working" (
"id" INTEGER NOT NULL,
"FirstName" RUS_FIO collate PXW_CYRL,
"MiddleName" RUS_FIO collate PXW_CYRL,
"LastName" RUS_FIO collate PXW_CYRL,
"fio" COMPUTED BY ("MiddleName"||" "||"FirstName"||" "||"LastName"),
"id_proffesion" INTEGER,
"rating" INTEGER);

/* Primary keys definition */

ALTER TABLE "employee_working" ADD CONSTRAINT "PK_employee_working" PRIMARY KEY ("id");

/* Foreign keys definition */

ALTER TABLE "employee_working" ADD CONSTRAINT "FK_employee_working2" FOREIGN KEY ("id_proffesion") REFERENCES "profession" ("id") ON DELETE SET NULL ON UPDATE CASCADE;

/* Indices definition */

CREATE INDEX "IDX_id_e" ON "employee_working" ("id");

SET TERM ^ ;

/* Triggers definition */

/* Trigger: "employee_working_BD" */
CREATE TRIGGER "employee_working_BD" FOR "employee_working" ACTIVE
BEFORE DELETE POSITION 0
AS
BEGIN
delete from "installation_of_ telephones" o
where o."id_owner" = old."id";
END
^

SET TERM ; ^

/* Таблица: profession */

CREATE TABLE "profession" (
"id" INTEGER NOT NULL,
"profession_txt" RUS_TXT_200 collate PXW_CYRL);

/* Primary keys definition */

ALTER TABLE "profession" ADD CONSTRAINT "PK_profession" PRIMARY KEY ("id");

/* Indices definition */

CREATE INDEX "IDX_id_prof" ON "profession" ("id");

SET TERM ^ ;

/* Triggers definition */

/* Trigger: "AI_profession_id" */
CREATE TRIGGER "AI_profession_id" FOR "profession" ACTIVE
BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW."id" IS NULL) THEN
NEW."id" = GEN_ID("profession_id_GEN", 1);
END
^

SET TERM ; ^

запрос такой:
select t1."fio", t2."profession_txt" from "employee_working" t1 join "profession" t2 on t1."id_proffesion"=t2."id" where t1."id"=:id_employee
план:
PLAN MERGE (SORT (T1 NATURAL),SORT (T2 NATURAL))

← →
Zacho © (2003-05-27 14:33) [14]

> plans (27.05.03 14:23)
> как?

Хорошенько подумать. Конкретную инструкцию для общего случая дать не могу.

> я хочу понять почему явное указание индекса не катит?

Ну синтаксис вроде правильный. Единственно, что приходит в голову - или ошибка в написании имени индекса, или какая-то заморочка с регистрозависимостью и кавычками в диалекте 3. Впрочем, если при создании индекса указывал имя большими буквами и без кавычек - то и в запросе пойдет без кавычек.
Глупое предположение: а индекс активен ?

← →
plans (2003-05-27 14:39) [15]

> Глупое предположение: а индекс активен ?

галочки стоят. у PK и FK - нет.

← →
plans (2003-05-27 14:45) [16]

вот попробовал запрос с order by - индексы не использует, если убрать order - то использует, как тут быть?

> plans (27.05.03 14:39)

Какие еще галочки ? Где ?
В общем, если индексы не активны - сделай активными. Если активны - собери по ним статистику. Дополнительные индексы по полям, входяшим в PK и FK - удали. После этого оптимизатор и сам должен построить нормальный план.
Еще несколько советов:
1. У тебя "id_proffesion" INTEGER допускает NULL и при этом в запросе join "profession" . Так и надо ? Или все-таки надо left join (или NOT NULL) ?
2. Триггер /* Trigger: "employee_working_BD" */ нафиг не нужен, достаточно для installation_of_ telephones создать FK с ON DELETE CASCADE
3.Так ли тебе нужна регистрочуствительность имен объектов
БД ? При создании метаданных пиши все имена большими буквами и без кавычек - избежишь разнообразных наступаний на грабли.

← →
plans (2003-05-27 14:59) [18]

> Дополнительные индексы по полям, входяшим в PK и FK - удали

у меня их и не было раньше. когда я их сделал - быстрее стало работать.

> plans (27.05.03 14:59)

Да не нужны они. Разве только для ручного задания плана. Но для такого запроса план и оптимизатор должен построить оптимальный. Конечно, если индексы активны. Так что если индексы по PK и FK не активны - немедленно сделай активными.

← →
plans (2003-05-27 15:26) [20]

> Какие еще галочки ? Где ?

это в IBManager можно посмотреть индексы - если он активен, то стоит галочка. Так вот на PK и FK - галочки нет и поставить ее не могу.

> plans (27.05.03 15:26)

Выкинь IBManager :-)
Ну активируй их запросом, в крайнем случае - убей PK и FK и создай заново.

а вместо IBManager используй отличную вещь: IBExpert

Почему не могу явно указать имя индекса? Найти похожие ветки