Решается задача портирования с FB 1.5.5.4926 на FB 3.0.2.32703. Периодически возникают вопросы по скорости работы запросов. Как правило всё решается убиранием "+0" или добавлением в разные места. Т.е. запрос, работающий на FB 1.5 быстро с "+0", на FB 3 тормозит, убираем - работает хорошо. Ну и наоборот, где работало без "добавок" на FB 3 надо дописывать "+0".

И тут вопрос быстродействия возник у запроса с простой выборкой данных, почти без какой-либо логики. Работает он на FB 3 в три раза дольше, чем на FB 1.5. Привожу текст:

SELECT G.KOD, G.PARENT FROM GOODS G where (G.PARENT is not null)

Результат 11594 записей.

FIREBIRD 1.5
PLAN (G NATURAL)
Время подготовки запроса = 0ms
Время выполнения запроса = 47ms
Среднее время на получение одной записи = 0,00 ms
Current memory = 27 649 480
Max memory = 28 506 036
Memory buffers = 3 000
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 34 302

FIREBIRD 3
PLAN (G NATURAL)
Select Expression
-> Filter
-> Table "C_GOODS" as "G" Full Scan
Время подготовки запроса = 0ms
Время выполнения запроса = 156ms
Среднее время на получение одной записи = 0,01 ms
Current memory = 28 822 256
Max memory = 29 052 592
Memory buffers = 3 000
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 21 387

Что тут можно подпилить в запросе - не понимаю. Оба сервера Classic, работают на одном компьютере на разных портах. Подключение через LocalHost. Базы после Restore. Тесты в IBExpert.

Может кто подскажет какие идеи?

Единственная версия того, почему есть разница в скорости выборки, это то, что данная таблица занимает по данным статистики в FB 3 больше чем в FB 1.5 (в FB 3 её размер 9.633 МБайт а в FB 1.5 размер 3.645 МБайт). Хотя таблица одна и та же, разбухла после B/R с FB 1.5. на FB 3.

С проблемой разобрался. Причина была в наличии COMPUTED BY полей. Кажется (могу ошибаться), FB 3 сохраняет их вместе с остальными данными в базе. Из-за этого та же самая таблица после переноса с FB 1.5 на FB 3 стала занимать больше места. После удаления COMPUTED BY полей статистика выровнялась.

Спасибо за участие!

На скорую руку сверстал пример. Примерно тот, что был тогда.

Внизу ниже структура базы данных, процедура для её заполнения. Во вложении картинка статистики.

CREATE TABLE LOOKUPTABLE (
ID INTEGER NOT NULL,
BIGSTRING VARCHAR(24000)
);

CREATE TABLE GOODS (
KOD INTEGER NOT NULL,
PARENT INTEGER,
BIGSTRING COMPUTED BY ((select bigstring from lookuptable where lookuptable.id = goods.parent))
);

ALTER TABLE GOODS ADD CONSTRAINT PK_GOODS PRIMARY KEY (KOD);
ALTER TABLE LOOKUPTABLE ADD CONSTRAINT PK_LOOKUPTABLE PRIMARY KEY (ID);

SET TERM ^;

CREATE PROCEDURE FILL
AS
declare variable i integer = 0;
declare variable s varchar(24000) = '';
begin
while (i < 24000) do
begin
s = s || 'x';
i = i + 1;
end
i = 0;
while (i < 10000) do
begin
insert into lookuptable(id, bigstring) values (:i, :s);
insert into goods(kod, parent) values(:i, :i);
i = i + 1;
end
end^

SET TERM ;^

execute procedure fill;

commit;

Проверил. Подтверждаю. Если таблица заполняется "с нуля", проблемы нет. Если таблица ресторится, то "пухнет".