|
Запрос, как найти соседние строки?
|
|||
---|---|---|---|
#18+
Симонов Денисс оконными функциями колёса покруглей будут Имелось виду нечто вида Код: sql 1. 2. 3. 4. 5. 6. 7.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2015, 12:22 |
|
Запрос, как найти соседние строки?
|
|||
---|---|---|---|
#18+
afgm, имелось ввиду именно то, что я написал. В твоём варианте предикаты не будут проталкиваться внутрь CTE, что обречёт на FULL SCAN таблицы movements даже при наличии любых индексов. Фильтр для user_id я не ставил потому, что надо для каждого сотрудника вывести было. Хотя чисто в теории user_id мог бы проталкиваться внутрь для данного конкретного случая, т.к. не влияет на конечный результат. Но в FB оптимизатор пока ещё не достаточно умён и приходится самому запихивать его внутрь CTE. Вторую задачку с уколами уже так легко не решить. По крайней мере эффективно решить весьма затруднительно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2015, 12:48 |
|
Запрос, как найти соседние строки?
|
|||
---|---|---|---|
#18+
Симонов Денисимелось ввиду именно то, что я написал. На самом деле цель понятна, но под каждый случай нужен свой запрос. Наличие рассчитанного to_date позволяет всегда индексироваться и выполнять веселее. А ещё to_date для последней даты удобно держать в виде 31.12.2999, дабы не играться с null-ами. Ну и prev_state_id, prev_record_id материализовать уже по случаю. Запросы такие часты, и каждый раз городить огород... В FB нет параметризованных вьюшек, значит CTE-всегда. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2015, 13:06 |
|
|
start [/forum/topic.php?fid=40&gotonew=1&tid=1562615]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 250ms |
total: | 391ms |
0 / 0 |