|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
Приветствую Firebird 3.0 Пытаюсь разобраться, как получить срез последних по времени данных есть таблица: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
набросал запрос который, вроде работает Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
План: PLAN SORT (SORT (MD M INDEX (MESSAGES_TIME))) Можно ли обойтись без with, и какие нужны индексы чтобы не вычитывать все записи за сутки? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2019, 18:39 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
Корректный план Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2019, 18:42 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
vvvaitМожно ли обойтись без with разве что заменить на derived table vvvaitкакие нужны индексы чтобы не вычитывать все записи за сутки никакие. Оконные функции никаких индексов применять не умеют, кроме тех по условию во внутреннем WHERE. Посмотри лучше explain план, тогда поймёшь как оконные функции выполняются. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2019, 19:46 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
похоже оконные функции не очень подходят для этой задачи если сделать временную таблицу: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
и выполнить такой блок: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
то получится тоже самое, только в 2,5 раза быстрее чем у оконной функции: ------ Информация о производительности ------ Время подготовки запроса = 32ms Время выполнения запроса = 2s 515ms Среднее время на получение одной записи = 104,79 ms Current memory = 42 256 536 Max memory = 113 440 272 Memory buffers = 2 048 Reads from disk to cache = 0 Writes from cache to disk = 0 Чтений из кэша = 91 461 ------ Информация о производительности ------ Время подготовки запроса = 15ms Время выполнения запроса = 6s 406ms Среднее время на получение одной записи = 206,65 ms Current memory = 40 992 888 Max memory = 113 440 272 Memory buffers = 2 048 Reads from disk to cache = 1 Writes from cache to disk = 8 Чтений из кэша = 26 189 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2019, 00:10 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
vvvait, а чего такой кеш мизерный? Ну и во вторых, конечную сортировку лучше ставить после всех фильтраций, т.е. вот так Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2019, 08:47 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
vvvait, и ещё зачем столько составных индексов? У вас есть запросы которые по всем полям одновременно фильтрацию делают? Достаточно одного индекса Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2019, 08:50 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
Индексы может и не все нужны, но это замедляет только вставку. Без сортировки, запрос идет 5 секунд. Кэш маленький, т.к. firebird крутится на роутере с 256 Мб памяти. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2019, 10:52 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
vvvait, Одиночный индекс в данном случае лучше Потому что Range Scan (full match) лучше чем Range Scan (partial match: 1/4) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2019, 11:10 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
перенес базу на core i5 8400, 16gb, ssd m.2 срез за 30 дней с окнами: ------ Информация о производительности ------ Время подготовки запроса = 16ms Время выполнения запроса = 8s 234ms Среднее время на получение одной записи = 111,27 ms Current memory = 36 679 880 Max memory = 111 302 032 Memory buffers = 2 048 Reads from disk to cache = 7 498 Writes from cache to disk = 4 Чтений из кэша = 437 180 без окон: ------ Информация о производительности ------ Время подготовки запроса = 0ms Время выполнения запроса = 1s 297ms Среднее время на получение одной записи = 17,53 ms Current memory = 36 768 864 Max memory = 111 302 032 Memory buffers = 2 048 Reads from disk to cache = 6 266 Writes from cache to disk = 6 Чтений из кэша = 2 156 679 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2019, 11:13 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
vvvait, а ещё GUID в качестве ключа здесь играет злую шутку. Был бы обычный авто инкремент можно было бы сделать так Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
потому что чем позже пришло сообщение тем больше ID В вашем случае можно попробовать Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2019, 11:31 |
|
Оконные функции для получения среза последних данных
|
|||
---|---|---|---|
#18+
там есть такое поле, но оно не уникально, и есть очень маленькая вероятность что будет две записи с одинаковым тиком Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
это запрос быстрее всех, на 30 дней: ------ Информация о производительности ------ Время подготовки запроса = 16ms Время выполнения запроса = 703ms Среднее время на получение одной записи = 9,50 ms Current memory = 36 809 368 Max memory = 111 302 032 Memory buffers = 2 048 Reads from disk to cache = 7 523 Writes from cache to disk = 4 Чтений из кэша = 437 233 второй запрос, с макс по времени, сработал за такое же время ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2019, 12:00 |
|
|
start [/forum/topic.php?fid=40&fpage=24&tid=1560740]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
44ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
others: | 296ms |
total: | 438ms |
0 / 0 |