Оптимизатор и VIEW c UNION ALL

[Veterok]

Всем привет
Нарвался на нездоровую вещь: есть две таблицы и view

CREATE TABLE A (
CODE_A INTEGER NOT NULL,
NAME_A VARCHAR (70),
CONSTRAINT ID_A PRIMARY KEY(CODE_A));

CREATE TABLE B (
CODE_B INTEGER NOT NULL,
NAME_B VARCHAR (70),
CONSTRAINT ID_B PRIMARY KEY(CODE_B));

CREATE VIEW V_A_AND_B(
CODE,
NAME)
AS
SELECT CODE_A,
NAME_A
FROM A
UNION ALL
SELECT CODE_B,
NAME_B
FROM B;

Нездоровая вещь в том, что при выполнении запроса

SELECT *
FROM V_A_AND_B
WHERE CODE = 1

оптимизатор не берет индексы ID_A и ID_B, хотя должен, как это делает Oracle. Куда бежать, кого стрелять?

[McArty]

Всем привет
Нарвался на нездоровую вещь: есть две таблицы и view

CREATE TABLE A (
CODE_A INTEGER NOT NULL,
NAME_A VARCHAR (70),
CONSTRAINT ID_A PRIMARY KEY(CODE_A));

CREATE TABLE B (
CODE_B INTEGER NOT NULL,
NAME_B VARCHAR (70),
CONSTRAINT ID_B PRIMARY KEY(CODE_B));

CREATE VIEW V_A_AND_B(
CODE,
NAME)
AS
SELECT CODE_A,
NAME_A
FROM A
UNION ALL
SELECT CODE_B,
NAME_B
FROM B;

Нездоровая вещь в том, что при выполнении запроса

SELECT *
FROM V_A_AND_B
WHERE CODE = 1

оптимизатор не берет индексы ID_A и ID_B, хотя должен, как это делает Oracle. Куда бежать, кого стрелять?

Попробуй так

CREATE VIEW V_A_AND_B(
CODE,
NAME)
AS
SELECT CODE_A,
NAME_A
FROM A
where CODE_A >0
UNION ALL
SELECT CODE_B,
NAME_B
FROM B
where CODE_B >0;

Вроде как можно заставить использовать индексы

[kdv]

я бы не сказал, что это вещь нездоровая, т.к. where на view накладывается снаружи, то есть к результату выполнения запроса view. а результат этот получен операцией union all, то есть, является виртуальным результатом слияния двух таблиц (запросов).
То есть, ситуация похожая на выборку из процедуры, когда для сервера процедура это черный ящик. И фильтрация результата процедуры может быть произведена только снаружи.

Хотя, в этом плане в FB 2.0 определенные подвижки есть (насчет view).

[Veterok]

Всем привет
Нарвался на нездоровую вещь: есть две таблицы и view

CREATE TABLE A (
CODE_A INTEGER NOT NULL,
NAME_A VARCHAR (70),
CONSTRAINT ID_A PRIMARY KEY(CODE_A));

CREATE TABLE B (
CODE_B INTEGER NOT NULL,
NAME_B VARCHAR (70),
CONSTRAINT ID_B PRIMARY KEY(CODE_B));

CREATE VIEW V_A_AND_B(
CODE,
NAME)
AS
SELECT CODE_A,
NAME_A
FROM A
UNION ALL
SELECT CODE_B,
NAME_B
FROM B;

Нездоровая вещь в том, что при выполнении запроса

SELECT *
FROM V_A_AND_B
WHERE CODE = 1

оптимизатор не берет индексы ID_A и ID_B, хотя должен, как это делает Oracle. Куда бежать, кого стрелять?

Попробуй так

CREATE VIEW V_A_AND_B(
CODE,
NAME)
AS
SELECT CODE_A,
NAME_A
FROM A
where CODE_A >0
UNION ALL
SELECT CODE_B,
NAME_B
FROM B
where CODE_B >0;

Вроде как можно заставить использовать индексы

Спасибо за ответ, но хотелось бы не наколоть оптимизатор, а реально заставить запрос работать при этих условиях быстро

[Veterok]

я бы не сказал, что это вещь нездоровая, т.к. where на view накладывается снаружи, то есть к результату выполнения запроса view. а результат этот получен операцией union all, то есть, является виртуальным результатом слияния двух таблиц (запросов).
То есть, ситуация похожая на выборку из процедуры, когда для сервера процедура это черный ящик. И фильтрация результата процедуры может быть произведена только снаружи.

Хотя, в этом плане в FB 2.0 определенные подвижки есть (насчет view).

Готов поспорить, что вещь эта все-таки нездоровая. Скорее всего спорить надо с разработчиками, т.к. имеет смысл сначала ограничить все объединенные запросы, а потом их объединять (что и делают другие СУБД). А что за подвижки насчет view в FB 2.0?

[McArty]

Что в FB 2 ?
p.s. Чаго ждать? Качаем,ставим и тестим.

[McArty]

Если интересно, то FB2 индексы с View и UNION ALL - использует как надо.

[kdv]

Скорее всего спорить надо с разработчиками, т.к. имеет смысл сначала ограничить все объединенные запросы, а потом их объединять

это не интерпретатор, а компилятор. запрос во View исполняется уже в скомпилированном виде. То есть сервер должен сконструировать blr из имеющегося во view и прилепленного снаружи.

тем более что про FB 2 я уже написал. Прежде чем спорить с разработчиками надо сначала ознакомиться с предметом, иметь представление о методах доступа в РСУБД, об архитектуре сервера (в части BLR) и знать об операциях над множествами.

[Veterok]

Скорее всего спорить надо с разработчиками, т.к. имеет смысл сначала ограничить все объединенные запросы, а потом их объединять

это не интерпретатор, а компилятор. запрос во View исполняется уже в скомпилированном виде. То есть сервер должен сконструировать blr из имеющегося во view и прилепленного снаружи.

тем более что про FB 2 я уже написал. Прежде чем спорить с разработчиками надо сначала ознакомиться с предметом, иметь представление о методах доступа в РСУБД, об архитектуре сервера (в части BLR) и знать об операциях над множествами.

согласен
спасибо

[kdv]

"не корысти ради...", и не в отношении конкретного вопроса. Но уж очень часто бывает, когда "почему оно не делает так, как я хочу". А оно "не делает" просто потому, что не существует математических способов осуществить подобное...

тем не менее, лично я сомневался, что для view подобное сделать можно. Ан нет, сотворили....

[dimitr]

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

Внешние условия над простыми view/derived table дописываются к их WHERE-кляузе. Внешние условия над UNION дописываются к WHERE всех подзапросов. Внешние условия над GROUP BY пропихиваются внутрь группировки, если применены к полям группировки, и т.п.