>ANB   (16.12.08 12:56) [19]
>FFS пошустрее будет. Проверялось.
в данном случае(индекс по date + id) придется пройти все листовые блоки, а т.к. такой индекс(по причине уникальности) содержит столько листовых элементов, сколько записей в table1(считаем, что id и date - not nullable).
пошустрее - это да, согласен, т.к. будет читать данные по порядку по листам индекса, а не метаться между блоками таблицы.
однако, вовсе не уверен, что это даст радикальный прирост по скорости).

>А вот NL - это, как я уже говорил, зависит от количества ID на одну дату. HASH может оказаться лучше.
здесь же NL будет всегда [b]не хуже[/b], hash join для t и t2

> здесь же NL будет всегда [b]не хуже[/b], hash join для t
> и t2

Пробовать надо.


> это даст радикальный прирост по скорости

Согласен.
Не больше чем в 1.5-2 раза. Во всяком случае СОЗДАВАТЬ индекс для отчета смысла нету. Если уже есть - то можно использовать, будет немного шустрее.

>Кщд   (16.12.08 07:11) [18]

А что, ИБ уже научили понимать вложеные запросы ?

MsGuns ©   (16.12.08 22:26) [22]
>А что, ИБ уже научили понимать вложеные запросы ?
отдельно оговаривалось, что речь об oracle
обсуждение началось с того, что использование индексов в данном случае нерационально

>SELECT * FROM table1 WHERE id IN (SELECT MAX(id) FROM table1 GROUP BY date)
речь шла об этом и только об этом запросе, а его IB6 должен бы понять

в моем примере (Кщд   (16.12.08 07:11) [18]) запрос был написан в форме, в которую указанный выше select будет преобразован oracle'ом при построении плана

> отдельно оговаривалось, что речь об oracle

тогда
select first_value("date") over (order by id,name,total)
from хрен_знает

>Petr V. Abramov ©   (17.12.08 23:29) [24]
>тогда
>select first_value("date") over (order by id,name,total)
>from хрен_знает
так мы получим ВСЕ данные из "хрен_знает" + last_value(id) over (partition by "date" order by id)

> Кщд   (18.12.08 07:43) [25]

я идею написал, понятно, что надо еще чуть-чуть букв :)