gmane.comp.db.firebird.russian

чтение данных типа hex

2012-05-15T06:02:40

я понимаю, что такого поля в firebird не существует, но если мы можем
записывать в поля данные по X'01010101', то почему мы так же их не
можем их считать в таком же формате, к примеру в select? Это здорово
упростило бы жизнь и совместимость с клиентами более ранних версий.
Я не уверен, что могу такие считать данные через perl.

Или я что-то пропустил в описании 2.5, или придется делать функцию
типа HEX()  в UDF, что не хотелось бы ))

WBRs, Евгений.

Запрос в FB2.5 выполняется дольше чем в FB2.0

Ice_Harley — 2012-05-08T13:22:20

Перевели базу с 2.0 на 2.5. Стало тормозить, полез разбираться и откопал 
следующую проблему:
Есть таблица, 22891 запись
CREATE TABLE U_GRANTS (
UID INTEGER_ NOT NULL /* INTEGER_ = INTEGER */,
OBJECT_TYPE INTEGER_ /* INTEGER_ = INTEGER */,
OBJECT VARCHAR_WIN1251_128 NOT NULL /* VARCHAR_WIN1251_128 = VARCHAR(128) 
*/,
SUB_OBJECT VARCHAR_WIN1251_128 COLLATE PXW_CYRL /* VARCHAR_WIN1251_128 = 
VARCHAR(128) */,
GUID VARCHAR_WIN1251_40 COLLATE PXW_CYRL /* VARCHAR_WIN1251_40 = 
VARCHAR(40) */,
GRANTS INTEGER_ NOT NULL /* INTEGER_ = INTEGER */,
MANUALLY INTEGER_ /* INTEGER_ = INTEGER */
);


CREATE INDEX IND_U_GRANTS_1 ON U_GRANTS (UID, OBJECT_TYPE, OBJECT); 
--селективность 0.00015
CREATE INDEX IND_U_GRANTS_2 ON U_GRANTS (OBJECT_TYPE, OBJECT); 
--селективность 0.00173
CREATE INDEX IND_U_GRANTS_3 ON U_GRANTS (OBJECT_TYPE, OBJECT, GUID); 
--селективность 0.00039

Есть запрос
SELECT COUNT(a.GRANTS)
FROM U_GRANTS a
WHERE a.OBJECT_TYPE = 2
AND a.OBJECT = 5162
AND a.GUID = '{CEDFF9C3-68D9-44C4-80EC-5A7F5044D6B0}'
AND a.GRANTS >= 10;

В 2.0 он выполняется 0ms и делает 17 чтений из таблицы.
В 2.5 он выполняется 31ms и делает 18267 чтений из таблицы.

Планы
--2.0
PLAN (A INDEX (IND_U_GRANTS_3))
--2.5
PLAN (A INDEX (IND_U_GRANTS_2))

Даже если вручную прописать план от 2.0, то запрос в 2.5 все равно делает 
18 тысяч чтений.

Что посоветуете?

Trigger

Dmitry Lendel — 2012-03-11T14:05:30

Привет
Есть две таблицы.
Master и Details

В таблице мастер есть триггер перед обновлением
  new.masterfield=9
  update Details set Somefiled = Value where ...

В таблице детали есть триггер перед обновлением
Select masterfield from Master where ...

Странно то, что этот запрос возвращает значение мастера до обновления. т.е. 
предыдущее. Так должно быть?
2.1.4

Дмитрий

Упала база, упала на пол...

Dumitru Condrea — 2012-03-07T05:11:32

День добрый,

Упала база. Firebird 1.5.

После танцами с 
- gfix-ом (-mend), 
- gbak-ом (бакап/ресторе с инактивными индексами) 
- пересозданием базы из скрипта

при активации одного из индекса выдаёт ошибку:

Unsuccessful execution caused by system error that precludes
successful execution of subsequent statements.
internal gds software consistency check (partner index description not 
found (175))

Что делать? Куда "копать"?

Различия версий снапшотов

reshetnyakvkt — 2012-03-05T09:18:09

Здравствуйте. Решил обновить версию сервера. Так вот, чем принципиально
отличается снэпшоты выложеные здесь "http://www.dqteam.com/fb2/" и здесь
"http://web.firebirdsql.org/download/snapshot_builds/linux/fb2.5/" ?
Догадываюсь что они собраны разными людьми, и в разное время. Т.е. содержат
разные изменения, и по сути представляют разные версии. Что же мне ставить в
производство, чему отдать предпочтение? Или тут уж "как карта ляжет"? Или
вопрос откуда чаще качают?

--
View this message in context: http://firebird.1100200.n4.nabble.com/-tp4445515p4445515.html
Sent from the firebird-russian mailing list archive at Nabble.com.

печалька для тестеров execute block+STATEMENT+ON EXTERNAL

Boltik Evgeny — 2012-03-03T00:11:02

Добрый день.

(время мин:сек) Задача подключится на локальной машине к соседней базе и
скопировать записи таблицы.
В надежде ускорить вставку был в недоумении.
Думая что execute block+STATEMENT к другой базе даст прирост при вставке
переписал код.
Но каково было удивление, что прирост был не велик
вместо 26:36 стало 25:05 прирост 1:31
в другом случае 6:.55 стало 6:15 прирост 00:40.
Решил посмотреть затраты на подготовку данных по старому получил 0:40 и
0:11. Получается основное время на вставку тратит сервер, а временем
подготовки данных можно пренебречь. Я раньше считал, что мой код через
параметры и variant тормозной, но оказалось что он ничтожно мало тратит по
сравнению с сервером.
На SSD картина получше. Не представляю как те у кого миллионы вставок.

PS.Получаем удобство в написании, но теряем возможность получить ошибку и
продолжить вставку, если надо продолжить. Бум надеяться на будущие.

Firebird 3.0.0.29767

Anton Zibrov — 2012-01-30T19:16:42

Добрый день, уважаемые!

Решил установить и помучать сабж...
получил:

Your user name and password are not defined. Ask your database 
administrator to set up a Firebird login.
Install incomplete, please read chapter "Initializing security database" 
in Quick Start Guide.

Quick Start Guide для 3.0 не нашел.

Что делать?

Проблемы при использовании временных таблиц с индексами

plasmorf — 2012-01-20T05:33:02

Доброе время суток.
Сервер FB 2.5.1 64 бит
есть база, в которой процедуры используют временные таблицы  ON COMMIT
DELETE ROWS с индексом по 3-м полям: integer, smallint, date
Проблема заключается в следующем:
Если после коннекта вызвать процедуру, использующую временную таблицу,
то первый раз все проходит нормально, однако если после выполнения
подтвердить или откатить транзакцию и в этом же коннекте запустить
процедуру еще раз, то вылазит ошибка: cannot add index, index root
page is full.
После пререподключения ситуация возобновляется - первый вызов
нормально, второй с ошибкой не смотря на то что они в разных
транзакциях

Чудеса при замене SQL-сервера FB 1.5 32bit --> FB 2.5 64bit

Ovchinnikov Vasily — 2012-01-17T08:25:07

То ли лыжи не едут...

Сообщения об ошибках не сохранял, пишу по памяти. Ибо дело было на прошлой неделе у одного из клиентов.
Времени на разбор особо не было - спешил отдать сервер в работу. Да и мысли в нужном русле потекли только
сегодня.

На столе подобное в лабораторных условиях воспроизвести нет возможности - нет 64битной винды под руками.

Выход-то он всегда есть, и он, в принципе проверенный: делай бэкап старой версией сервера, а рестор - новой
версией сервера. Но я забегаю вперед.

При переводе одного из клиентов с 1.5 на 2.5 (на сервере ось Win2008-64бит) обнаружил, что GBAK не может
подключиться к базам данных, созданными Firebird 1.5 32бит, в среде Win2008-64бит.

А обнаружил я это, поспешив и снеся прежде всего Firebird 1.5 (32бит), который там до того крутился.
Да, 32-битная полуторка крутилась под 64-битной виндой. Никакого вроде бы криминала.

Установил Firebird 2.5 (64 бит) и только потом стал пытаться делать бэкап баз GBAK'ом.
Начал с полуторного security.fdb - ошибка подключения.
Попробовал бэкапнуть рабочую базу - та же ошибка подключения. Типа база в неверном формате.

Накатил заново Firebird 1.5, бэкапнул security.fdb и рабочую базу, и совершенно спокойно завершил все
регламентные работы (подмена security.fdb, апгрейд метаданных и пр.)

Задумался только теперь вот: а действительно ли это правильное поведение GBAK от Firebird 2.5(64) - не
подключиться к базе, созданной Firebird 1.5(32) ?..

Пробовал "в лаборатории" только тот вариант с Win7-32бит, в котором GBAK от Firebird 2.5 (32) нормально
подключается к базе с ODS 10.1, созданной Firebird 1.5 (32). В этом-то варианте без сучка и задоринки все
проходит и это никогда не было для меня тайной... GBAK от 2.5 в этой конфигурации системы спокойно хавает базу
с ODS 10.1 для создания бэкапа.

Да, протокол подключения - TCP.
Т.е. коннект к базе вида localhost:d:\bases\mybase.fdb

Вывод номеров строк с помощью SQL запроса

Мякотин Сергей — 2012-01-12T08:40:04

Сделал процедуру вывода номеров строк, и обнаружил странное поведение 
оптимизатора и сортировки

create procedure GET_ROW_NUM(
  DUMMY blob = null)  -- Нужно указавать в случае union all например, т.к. 
оптимизатор выполняет запрос 1 раз
returns (
  NUM integer)
as
begin
  if (RDB$GET_CONTEXT('USER_TRANSACTION', 'LastSetNum') <> 
current_timestamp)
     then RDB$SET_CONTEXT('USER_TRANSACTION', 'RowNumber', null);
  NUM = coalesce(RDB$GET_CONTEXT('USER_TRANSACTION', 'RowNumber'), 1);
  RDB$SET_CONTEXT('USER_TRANSACTION', 'RowNumber', NUM + 1);
  RDB$SET_CONTEXT('USER_TRANSACTION', 'LastSetNum', current_timestamp);
  suspend;
end

надеюсь то, что current_timestamp не меняется в рамках одного запроса не 
изменится в следующих версиях, или как?

использование:

select
  (select NUM from GET_ROW_NUM),
  r.RDB$RELATION_NAME
from RDB$RELATIONS r

странно, но в данном случае процедура выполняется нужное мне кол-во раз

select
  (select NUM from GET_ROW_NUM),
  r.RDB$RELATION_NAME
from RDB$RELATIONS r
union all
select
  (select NUM from GET_ROW_NUM),
  r.RDB$RELATION_NAME
from RDB$RELATIONS r

а в этом случае как и ожидалось - только два раза, решается просто

select
  (select NUM from GET_ROW_NUM(r.RDB$RELATION_NAME)),
  r.RDB$RELATION_NAME
from RDB$RELATIONS r
union all
select
  (select NUM from GET_ROW_NUM(r.RDB$RELATION_NAME)),
  r.RDB$RELATION_NAME
from RDB$RELATIONS r

а вот с сортировкой вообще непонятно, я почему-то думал, что сначала 
производится формирование массива, его сортировка и вывод, а оказалось что 
это (select NUM from GET_ROW_NUM) выполняется не 42 раза а 84

select
  (select NUM from GET_ROW_NUM),
  r.RDB$RELATION_NAME
from RDB$RELATIONS r
order by 1 desc

ps.

Firebird SS 2.5.1

Где релизноты в ubuntu

Tonal — 2011-12-23T09:15:37

Вроде, по описанию должны жить в пакете firebird2.5-doc
Ну или в firebird2.5-common-doc, в крайнем случае.
Но не там не там не наблюдается.

Кто в курсе где искать, куда смотреть?

Что-то непонятное с left join

Tonal — 2011-12-23T07:31:14

Есть табличка:
CREATE TABLE SYMPTOMS (
  ID integer not null,
  PARENT_ID integer,
  ORD_NUM integer
  -- отгрызено полей
  CONSTRAINT PK_SYMPTOMS PRIMARY KEY (ID),
  CONSTRAINT FK_SYMP2SYM_ID FOREIGN KEY (SYM_ID) REFERENCES SYMPTOMS (ID)
);

ORD_NUM - порядковый номер в отображении. Нумерация начинается с 1,
одинаковых и номеров и дырок не допускается.
Выбираю уровень:
SQL> select s.ID, s.ORD_NUM from SYMPTOMS s where s.PARENT_ID = 450774;

          ID      ORD_NUM
============ ============
      450775            1
      450776            2
      450777            3

Проверяю на существование дырок:
SQL> select s.ID, s.ORD_NUM, s2.ID, s2.ORD_NUM
CON> from SYMPTOMS s left outer join SYMPTOMS s2
CON> on s.ORD_NUM + 1 = s2.ORD_NUM
CON> where s.PARENT_ID = 450774 and s2.PARENT_ID = 450774
CON> /*and s2.ID is null*/;

          ID      ORD_NUM           ID      ORD_NUM
============ ============ ============ ============
      450775            1       450776            2
      450776            2       450777            3

Что за ерунда?
А где строка
      450777            3         null         null

В то же время
select * from RDB$DATABASE l
left join RDB$DATABASE r on l.RDB$RELATION_ID = r.RDB$RELATION_ID + 1
возвращает одну строку все поля от l в которой null - как и ожидалось/

Запрос с not exists отрабатывает нормально выдавая ожидаемую
450777            3

select s.ID, s.ORD_NUM
from SYMPTOMS s
where s.PARENT_ID = 450774
and not exists(
 select 1 from SYMPTOMS s2 where s2.PARENT_ID = 450774
 and s.ORD_NUM + 1 = s2.ORD_NUM
)

Что бы это могло быть?
б/р проходит без ошибок.

ОС Kubuntu 11.10 со всеми обновлениями
firebird2.5-super 2.5.0.26074-0.ds4-5 - из стандартного репозитория

firebird2.5-super Version: 2.5.1.26351.ds4-2~bpo60+1ubuntu3 - из ppa
Maintainer: Popa Adrian Marius

Путь к bin

Alexey Popov — 2011-12-16T06:10:49

Может кто уже решал подобную задачу? Нужно сделать bat файл, который бы 
интенсивно использовал утилиты fb из каталога bin. Причём без участия 
узера. Проблема в том, что пути нет в PATH и ничего не работает. Если 
способ извлечь в батник пусть из реестра?

Ещё вопросик. Есть ли способ вызывать isql не посредством указания 
input-файла, а через перенаправление ввода типа
echo exit; | isql base.db

Глюки в рекурсивном запросе

Tonal — 2011-12-12T10:59:04

Наткнулся на такую глючу.
В запросе ниже, выдаётся разные результаты при закомментированном и
раскомментированном group by, хотя вроде бы должны быть одинаковые.

with recursive
SYM as (
  select sr1.ID, sr1.PARENT_ID
  from SYMPTOMS sr1
  --group by 1, 2
),
TREE as (
  select 1 as LEV, sp.ID, sp.PARENT_ID
  from SYM sp where sp.ID = 450797
  union all
  select t.LEV + 1, st.ID, st.PARENT_ID
  from SYM st inner join TREE t on st.PARENT_ID = t.ID
)
select
  t.LEV, t.ID
from TREE t

Или меня опять подводит мой «здравый смысл»?
Пример возник из попытки написать проверку некоторого условия которое
зависит от родителей.
Т. е. SYM предполагался довольно сложным - вычисляющим данные для этого
условия.

ОС Kubuntu 11.10 i386
Сервер SS 2.5.0.26074 из стандартных реп.

Табличка:
CREATE TABLE SYMPTOMS (
  ID D_ID,
  PARENT_ID D_ID_OR_NULL,
  -- отгрызено полей
  CONSTRAINT PK_SYMPTOMS PRIMARY KEY (ID),
  CONSTRAINT FK_SYMP2SYM_ID FOREIGN KEY (SYM_ID) REFERENCES SYMPTOMS (ID)
);

Данные:
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450797', '450773');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450798', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450799', '450798');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450800', '450798');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450801', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450802', '450801');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450803', '450801');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645590', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645591', '645590');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645592', '645590');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645593', '645592');

delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

reshetnyakvkt — 2011-12-02T09:50:23

Установлена ОС Mandriva 2009 x64, 9Гб оперативки, винты 160Гб.
До этого стоял *FirebirdSS-2.5.0.25946-ReleaseCandidate3.amd64* конструкция
отваливает все залипшие коннекты из текущей БД, а далее и в цикле из всех
архивов. Работало безупречно:
  in AUTONOMOUS TRANSACTION
  do delete from MON$ATTACHMENTS where
MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION;
  --
  for
    select a_path from DYN_PATH_NAME_ARCH(null, 199901, 201110)
  into :PATH
  do begin
    IN AUTONOMOUS TRANSACTION
    DO BEGIN
      EXECUTE STATEMENT ('delete from MON$ATTACHMENTS'
        ||' where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION')
        ON EXTERNAL :PATH AS USER 'SYSDBA' PASSWORD :PASS;
    END
  end
После установки *FirebirdSS-2.5.1.26351-0.amd64*, такая конструкция валит
сервер наглухо. Приложения выполняющее этот запрос висит не реагируя. Не
помогает service firebird restart, а также stop/start. Зависшего процесса не
замечено. В логе firebird.log лишь несколько строк об ошибках с номерами и
стопа, запуска, перезапуска:
/INET/inet_error: read errno = 104
/opt/firebird/bin/fbguard: /opt/firebird/bin/fbserver terminated abnormally
(-1)
/opt/firebird/bin/fbguard: guardian starting /opt/firebird/bin/fbserver
INET/inet_error: bind errno = 98
/opt/firebird/bin/fbguard: /opt/firebird/bin/fbserver terminated due to
startup error (2)
INET/inet_error: read errno = 9
INET/inet_error: read errno = 104
/, и т.п.
Сама ось не висит. Только после перезагрузки оси роботоспособность
восстанавливается. Как вы понимаете это крайняя мера и не допустима. Это уже
второй раз так случается и прослеживается закономерность.
Вопрос к разработчикам что происходит. Если конструкция с
"MON$ATTACHMENTS.MON$ATTACHMENT_ID" больше не работает, то подскажите как
теперь без последствий отключать непослушные коннекты?

--
View this message in context: http://firebird.1100200.n4.nabble.com/delete-from-MON-ATTACHMENTS-where-MON-ATTACHMENTS-MON-ATTACHMENT-ID-CURRENT-CONNECTION-tp4145993p4145993.html
Sent from the firebird-russian mailing list archive at Nabble.com.

offtopic - прога по недвижимости

Sergey Mereutsa — 2011-11-28T12:20:45

Привет!

Народ, если кто занимается прогами, связанными с недвижимостью
(продажа/покупка/агенты) - свистните мне в мыло на serj собака dqteam
ком - может что-нибудь вкусное всем перепадёт.

Проверить существование учетной записи пользователя

A K — 2011-11-27T18:01:07

На радостях заменил в проекте весь код создания/удаления учетных записей 
пользователей с сервисов на команды CREATE USER/DROP USER.

Но, вот незадача, как сделать проверку существования учетной записи
без обращения к сервисам?

Пока, ничего умнее

alter user yyy set middlename ''

и отлова ошибки с GDSCode = 336723990 на ум не приходит.

Проблема с уникальным индексом на 2.5.1

A K — 2011-11-23T14:07:21

В базе есть уникальный индекс по двум строковым полям. База перестала
восстанавливаться из архива. Восстанавливаем без индексов.
Пытаемся воссоздать этот индекс -- ругается на наличие повторяющихся 
строк. Но,

1) запрос с группировкой показывает что повторяющихся строк НЕТ.
2) более того, первое поле в индексе содержит только уникальные значения.
3) была идея, что наличие NULL в некоторых строках во второй колонке
индекса приводит к такому эффекту, но замена NULL на пустые строки
все равно не дает создать индекс.

Что за проблема? Если что, базу могу на какой ФТП залить.

Андрей

new / delete в UDF

Vladimir — 2011-11-17T20:45:04

Здравствуйте!

При попытке в Linux использовать UDF, собранную в gcc, столкнулся со
следующим:

long* aTestItem = new long;
delete aTestItem;

вызывает ошибку Segmentation fault на операторе delete.

В Windows все проходит без ошибок.

Если библиотеку использовать не в UDF, а вызывать из простого
тестового приложения, все проходит без ошибок и в Linux.

Есть ли возможность использовать в UDF в Linux операторы new / delete?

Речь идет не о возвращаемом результате, все происходит внутри UDF.

Если заменить new / delete на malloc / free, ошибки не возникает.
Но в UDF требуется работать с классами.
Как вариант, рассматриваю возможность размещать экземпляры классов по
malloc с последующим явным вызовом конструкторов.
Но используемая система классов достаточно громоздкая.
Кроме того, хотелось бы минимизировать отличия между Windows и Linux
версиями.

Поэтому вопрос для меня очень насущный.

Есть ли возможность использовать в UDF в Linux операторы new / delete?

С уважением, Владимир.

Тозмоза простейших запросов

Alexey Popov — 2011-11-11T07:21:26

Ранее я писал:


Виноват оказался sweep. Вот наиболее важные свойства базы:

         Database size : 1409 Mb
Page size8192
ODS version11.0
Oldest transaction67773710
Oldest active67773711
Oldest snapshot67773711
Next transaction67786537
Sweep interval:20000

Как вижно разница скоро достигнет 20000 и сработает sweep. Почему 
транзацкции застревают - это отдельный вопрос, ранее такого не было.
Может быть rollback виноват???

Основной вопрос в том, почему sweep полностью блокирует работу сервера 
даже на запросе
execute block as begin post_event 'my_event'; end
?

Оптимизатор 2.5.2 : учёт взаимодействия FK, JOIN, DISTINCT, GROUP BY в простейших случаях

Arioch — 2011-11-08T11:38:30

Таблица Objects (integer idx not null Primary key и еще столбцы)
Таблица Metrics (integer idx not null Primary key, integer Object not null  
-> FK на Objects.idx, double Turn индексированное);

Составлял запросы по частям, типа REPL


Дальше ряд вроде бы одинаковыx запросов.

select  m.object /* o.idx */ as object_idx, max (m.turn) as max_turn
  from /* objects o, */ metrics m
where /* m.object = o.idx and */ m.turn > 45
group by m.object
order by 2 descending
--------------
PLAN SORT ((M ORDER FK_METRICS_1 INDEX (METRICS_IDX2)))

select distinct m.object /* o.idx */ as object_idx, max (m.turn) as  
max_turn
  from /* objects o, */ metrics m
where /* m.object = o.idx and */ m.turn > 45
group by m.object
order by 2 descending
--------
PLAN SORT (SORT ((M ORDER FK_METRICS_1 INDEX (METRICS_IDX2))))

select distinct  m.object /*  o.idx */ as objecy_idx, max (m.turn) as  
max_turn
  from  objects o,  metrics m
where  m.object = o.idx and m.turn > 45
group by m.object
order by 2 descending
--------------
PLAN SORT (SORT (JOIN (M ORDER FK_METRICS_1 INDEX (METRICS_IDX2), O INDEX  
(PK_OBJECTS))))

select m.object /*  o.idx */ as object_idx, max (m.turn) as max_turn
  from  objects o,  metrics m
where  m.object = o.idx and m.turn > 45
group by m.object
order by 2 descending
--------------
PLAN SORT (JOIN (M ORDER FK_METRICS_1 INDEX (METRICS_IDX2), O INDEX  
(PK_OBJECTS)))


1) Насколько понимаю, в присутсвии Group By, distinct тут не играет  
никакой роли, она автоматически получается ? Но оптимизатор добавляет  
безындексную сортировку.
2) Учитывая, что из таблицы Objects мы не выбираем значений (кроме FK), а  
наличие самой соотв. строки обеспечивается через FK, то добавлять её в  
план не нужно.


----------------------------------

select distinct /* m.object */   o.idx  as object_idx, max (m.turn) as  
max_turn
  from  objects o,  metrics m
where  m.object = o.idx and m.turn > 45
group by /* m.object */  o.idx
order by 2 descending
--------------
PLAN SORT (SORT (SORT (JOIN (M INDEX (METRICS_IDX2), O INDEX  
(PK_OBJECTS)))))

select distinct  m.object /*   o.idx */ as object_idx, max (m.turn) as  
max_turn
  from  objects o,  metrics m
where  m.object = o.idx and m.turn > 45
group by  m.object /*  o.idx */
order by 2 descending
--------------
PLAN SORT (SORT (JOIN (M ORDER FK_METRICS_1 INDEX (METRICS_IDX2), O INDEX  
(PK_OBJECTS))))

Учитывая FK - запросы одинаковые, а план разный. Вотрой, вероятно, лучше.


-------------------------------