Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Топик навеян периодическими воплями на тему, что "наши временные таблицы - более "временные", чем ваши" ;-) Последний раз тему затронули вчера в соседнем топике. Разговор не ограничивается Oracle и MSSQL, так что апологеты других серверов могут подключаться. Итак, ведем дискуссию о реализации временных таблиц в различных серверах. Для начала заглянем в SQL-стандарт. Там мы видим во-первых деление на глобальные (далее GTT) и локальные (далее LTT) временные таблицы. GTT создаются с помощью CREATE GLOBAL TEMPORARY TABLE. Характеризуются глобальной видимостью метаданных (они лежат в общей схеме) и сеансовой видимостью данных. Т.е. наличие GTT видят все, но каждая сессия работает со своей копией данных. Если посмотреть на существующие СУБД, то почти все реализуют (с тем или иным синтаксисом) эту возможность. Исключения - DB2 (DECLARE GLOBAL, однако видимость метаданных сессионная), а также PostgreSQL и MySQL - нет этой фичи вообще. Один нюанс - MSSQL (и полагаю, что Sybase ASE также) разделяет данные GTT между сессиями. Никто больше этого не делает. LTT бывают <created> и <declared>. Первые создаются через CREATE LTT и характеризуются сессионной видимостью метаданных. Это означает, что две сессии могут создать разные по структуре CLTT с одинаковым имеем. Разумеется, видимость данных тоже сессионная. Oracle не поддерживает CLTT (как минимум в 9i), также как Sybase ASA и InterBase. Второй класс LTT создается через DECLARE LTT и подразумевает видимость (как метаданных, так и данных) только в пределах текущего модуля (SQL client module). Увы, стандартное понятие модуля достаточно туманно/спорно и, похоже, производители предпочитают трактовать DLTT как внутрипроцедурные таблицы. Oracle и MSSQL имеют такую возможность (в том или ином виде), на счет остальных СУБД у меня информации нет. На практике, лично у меня вообще очень редко возникала необходимость во временных таблицах. И если уж и возникала, то исключительно в GTT (сгенерить данные для сложного отчета процедурой и натравить потом на них Crystal Reports) или в DLTT (если процедурный расчет нельзя выполнить за один прогон исходных данных). Допускаю, что CLTT также могут быть полезны при вынесении логики из базы. У меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? Второй - какого фига мелкомягкие GTT разделяют данные? На кой тогда вообще это надо? Также хотелось бы услышать о ситуациях, в которых люди применяют временные таблицы. Особенно - почему нелья обойтись без них? Если кто-то хочет поговорить о других вещах, как-то: механизмы хранения временных данных или нюансы отработки ON COMMIT { PRESERVE | DELETE } ROWS - welcome. Если я в чем-то ошибся насчет какой-либо СУБД - поправьте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:43 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
IMHO Oracle не поддерживает локальные временные таблицы, потому-что это фактически DDL в продакт коде, т.е. очень очень плохо. Возможно MSSQL к этому относится терпимее но в Oracle это настоящий гиморой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:47 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Кстати, необходимость во временных таблицах вообще в Oracle возникает крайне редко. Практически любой отчет можно сформулировать одним запросом. И даже если запрос получится очень махровым оптимизатор с ним справится. До введения аналитических функций (8i) проблему представляли запросы типа "нарастающий итог", что касается "деревянных" расширений, они есть уже в 7-ке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:50 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторПервый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? во первых идеологическая проблема, на временые таблицы оракла можно вещать вью и тригеры, а это значит что дефиниция этой таблицы должна быть в словаре базы и соответственно не может быть разной для разных пользователей. наверника если задуматся это можно было бы как-то обойти с помощью синонимов и т.п. но поскольку мало кто придумал задачу в которой бы такое понадобилось, то и решать эту "проблему" видно не собираются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:57 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)IMHO Oracle не поддерживает локальные временные таблицы, потому-что это фактически DDL в продакт коде, т.е. очень очень плохо. Возможно MSSQL к этому относится терпимее но в Oracle это настоящий гиморой. Об этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма. Думать все начинают уже после того, как что-то не получилось :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:00 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Yo!во первых идеологическая проблема, на временые таблицы оракла можно вещать вью и тригеры, а это значит что дефиниция этой таблицы должна быть в словаре базы и соответственно не может быть разной для разных пользователей. Это не ответ. Ты описал возможности Оракла в отношении GTT. Кто им мешает ввести ограничения для LTT? И вообще, почему нельзя разграничить видимость словаря базы? Например, через namespace/schema + session_id? Т.е. это не идеологическая проблема, по крайней мере, в этом ракурсе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторOracle не поддерживает CLTT (как минимум в 9i), также как Sybase ASA и InterBase. В Sybase ASA есть - CREATE TABLE #TableName в целях совместимостью с MSSQL. Но этим пользоваться не интересно, так как на такую форму записи не навесишь различные параметры времянки (тот же флаг NOT TRANSACTIONAL), как в DECLARE LOCAL TEMPORARY TABLE. авторУвы, стандартное понятие модуля достаточно туманно/спорно и, похоже, производители предпочитают трактовать DLTT как внутрипроцедурные таблицы. Oracle и MSSQL имеют такую возможность (в том или ином виде), на счет остальных СУБД у меня информации нет. В ASA cуществует понятие блоков видимости и атомарности. Так что в этом коде: Код: plaintext 1. 2. 3. 4. 5. 6. 7. авторНа практике, лично у меня вообще очень редко возникала необходимость во временных таблицах. И если уж и возникала, то исключительно в GTT (сгенерить данные для сложного отчета процедурой и натравить потом на них Crystal Reports) или в DLTT (если процедурный расчет нельзя выполнить за один прогон исходных данных). То же самое один в один. Плюс иногда полезно через DLTT предварительно загнать небольшое кол-во многократно используемых и рассчитываемых данных, которые фигурируют в очень сложном и большом запросе, чтобы оптимизатор лишний раз не сходил с ума и видно, что от этого только выиграешь. авторТакже хотелось бы услышать о ситуациях, в которых люди применяют временные таблицы. Особенно - почему нелья обойтись без них? Если кто-то хочет поговорить о других вещах, как-то: механизмы хранения временных данных или нюансы отработки ON COMMIT { PRESERVE | DELETE } ROWS - welcome. Если я в чем-то ошибся насчет какой-либо СУБД - поправьте. В ASA помимо ON COMMIT { PRESERVE | DELETE } есть еще NOT TRANSACTIONAL. Вот и вся разница. Остальное тоже самое. Так же можно и триггера на GTT катать, очень удобно иногда. авторУ меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? Второй - какого фига мелкомягкие GTT разделяют данные? На кой тогда вообще это надо? Гм - зачем нужны CLTT, когда есть GTT - это гораздо удобнее. Думаю если бы у MSSQL и ASE были GTT, никто этими CLTT и не пользовался бы. Во вторых разделяют, потому как механизм так криво реализован по моему личному мнению. В ASE кстати номер с ## (глобальными MS времянками) вообще не прокатывает - нет там такого. Плюс эти ## у MSSQL имеют нехорошую тенденцию удалятся при завершении той сессии, которая их создала, так что лично я так и не смог придумать им хоть какое то разумное применение (может и плохо думал, кто знает). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:06 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Кстати, необходимость во временных таблицах вообще в Oracle возникает крайне редко. Практически любой отчет можно сформулировать одним запросом. И даже если запрос получится очень махровым оптимизатор с ним справится. Тут согласен, хотя оптимизатор зачастую все же не справляется. Т.е. получается, что богатый набор языковых фич в большинстве случаев отменяет необходимость во временных таблицах. Но так ли это на практике? ЗЫ. Щаз придут фанаты сиквела и все опровергнут ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:07 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
где-то неподалеку слышен тоскливый вой бродячей собаки.. и вот, гаснет свет и двери начинают меедленно открываться.. неужели это снова пришли ОНИ?? страшно? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:16 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitrОб этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма. Думать все начинают уже после того, как что-то не получилось :-( Нууу не надо быть Энштейном, чтобы понять - что одна СУБД воспринимает хорошо, то другая может воспринимать очччень плохо. Только не надо сразу говорить, что это минус. Это может быть и плюс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:17 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitrТут согласен, хотя оптимизатор зачастую все же не справляется. Т.е. получается, что богатый набор языковых фич в большинстве случаев отменяет необходимость во временных таблицах. Но так ли это на практике? Если оптимизатор в КОНКРЕТНОМ случае не справляется, это задача для тюнинга :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:19 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
я GTT в DB2 использую как правило в качестве меток к записям в пользовательской выборке. Присоединяешь к основной таблице левым джойном - и красота...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:19 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ASCRUSГм - зачем нужны CLTT, когда есть GTT - это гораздо удобнее. Чтобы создавать нужные таблицы динамически в сессиях, не заботясь о том, есть ли уже другие с такми же именем. Для меня это нонсенс, правда, но многие по-другому думать не умеют, похоже ;-) К слову, искренне рад за ASA. Хоть и не люблю блокировочники вообще (говорил уже, что готовить не умею), но ASA мне наиболее приятен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:20 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
в MS SQL глобальные временные таблицы лично я никогда не использовал (за ненадобностью, ИМХО), а вот локальные - да. Иногда, для помощи оптимизатору, я разбивал большой запрос с джоинами к многомилионным таблицам на пару-тройку более простых и промежуточные результаты записывал в локальную врем.таблицу. Потом появились переменные типа table и необходимость даже в локальных врем таблицах еще больше снизилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:22 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Локальные временные таблицы теоретически могут пригодиться, если каждый раз требуется таблица ДРУГОЙ структуры, но я не могу придумать задачу, в которой это было-бы НЕОБХОДИМО. И в Oracle, минусы от такой фичи существенно перевесят плюсы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
segunв MS SQL глобальные временные таблицы лично я никогда не использовал (за ненадобностью, ИМХО), а вот локальные - да. Иногда, для помощи оптимизатору, я разбивал большой запрос с джоинами к многомилионным таблицам на пару-тройку более простых и промежуточные результаты записывал в локальную врем.таблицу. Потом появились переменные типа table и необходимость даже в локальных врем таблицах еще больше снизилась. Аналогично. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Если оптимизатор в КОНКРЕТНОМ случае не справляется, это задача для тюнинга :) Или для баг-репорта производителю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:26 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
На моей (не очень богатой) практике не было случая, когда не удавалось найти какое-либо приемлимое решение НА МЕСТЕ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:28 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
В MS SQL одно из наиболее частых применений временных таблиц - сказать INSERT INTO #ttable EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно> Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:29 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenmanя GTT в DB2 использую как правило в качестве меток к записям в пользовательской выборке. Присоединяешь к основной таблице левым джойном - и красота...) Кстати да, про такое применение я и забыл. Вполне удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:30 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitrУ меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? Я бы сказал так: техническая возможность есть, но я отлично понимаю нежелание их делать. Оракл стремится перенести максимум нагрузки на этап компиляции кода и соответственно максимально разгрузить (и за счет этого убыстрить) этап выполнения. В ситуации, когда одна процедура создает таблицу, а другая делает из нее селект, о таком желании можно забыть. Соответственно, технически такая возможность есть (через динамический SQL), но это надо делать специально. Грубо говоря, компилятор не встраивает поддержку заведомо неэффективного режима. Мало того: уже достаточно давно существует поддержка nested tables, которые аналогичны подобным "сугубо временным" таблицам. То есть: из них можно делать селекты, также с ними можно работать как с массивами. dimitrОб этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма. Вопрос в том, что эти люди даже не пытаются думать об эффективности кода, который пишут. Перейдя на Оракл, люди - типично - начинают пытаться работать с ним именно так, не пытаясь разобраться, хорошо это (для Оракла) или плохо. Поэтому, полагаю, они и на родном сервере не задавались этим вопросом. В такой ситуации я всячески поддерживаю нежелание встраивать "фичу для торможения". Тем паче, что ни малейшей необходимости нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:45 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechКстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? А явные курсоры в Oracle НЕ ЕСТЬ ЗЛО ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:48 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Alex.CzechКстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? А явные курсоры в Oracle НЕ ЕСТЬ ЗЛО Да лана... пройтись курсором по тыще строчек - не есть зло ? :) Или есть все-таки какая-то возможность bulk collect-а из REF CURSOR ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:50 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Зависит от конкретной задачи. Ходить по 1000 строчек и в MSSQL не гут. Давайте не будем разводить на эту тему флейм, тема так хорошо началась :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:00 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Я не фанат, просто мне интересно как можно что-то делать без временных таблиц. Вот пример куска реального триггера на изменение остатков при вставке проводок автор declare @accstm_c table( bln varchar(15), fond varchar(15), date datetime, acc varchar(30), s dec(19,6), d dec(19,6), c dec(19,6)) insert @accstm_c select bln, fond, date, dacc acc, summa s, summa d, @nil c from inserted insert @accstm_c select bln, fond, date, cacc, -summa,@nil,summa from inserted insert @accstm_c select bln, fond, date, dacc, -summa,-summa,@nil from deleted insert @accstm_c select bln, fond, date, cacc, summa,@nil,-summa from deleted declare @accstm_p table( bln varchar(15), fond varchar(15), date datetime, acc varchar(30), s dec(19,6), d dec(19,6), c dec(19,6)) insert @accstm_p select bln,fond,date, acc, sum(s) s,sum(d) d,sum(c) c from @accstm_c -- изменение остатка, group by bln,fond,date,acc -- дебета и кредита при проводке insert @accstm_p select bln,fond,'20651031', acc, 0,0,0 from @accstm_p group by bln,fond, acc declare @accstm_d table( bln varchar(15), fond varchar(15), acc varchar(30), date1 datetime null, date2 datetime null) insert into @accstm_d select p.bln,p.fond,p.acc, p.date date1, min(s.date) date2 from @accstm_p p, @accstm_p s -- выбираются интервалы дат where p.bln=s.bln -- для вычисления поправок остатков and p.fond=s.fond and p.acc=s.acc and p.date<s.date group by p.bln,p.fond,p.acc, p.date declare @accstm_s table( bln varchar(15), fond varchar(15), acc varchar(30), date1 datetime null, date2 datetime null, s dec(19,6)) insert into @accstm_s select p.bln,p.fond,p.acc,d.date1 date1, d.date2, sum(p.s) s from @accstm_p p, @accstm_d d where p.bln=d.bln -- для вычисления поправок остатков and p.fond=d.fond and p.acc=d.acc and d.date1>=p.date group by p.bln,p.fond,p.acc, d.date1, d.date2 declare @accstm_n table( bln varchar(15), fond varchar(15), date datetime null, acc varchar(30), s dec(19,6)) insert into @accstm_n select bln,fond,date,acc,@nil s -- выборка недостающих состояний from @accstm_p p -- счетов where date<>'20651031' and (s<>0 or d<>0 or c<>0) and not exists(select * from AccState s where p.bln=s.bln and p.fond=s.fond and p.acc=s.acc and p.date=s.date) declare @accstm_v table( bln varchar(15), fond varchar(15), date datetime, acc varchar(30), dp datetime null) insert into @accstm_v select n.bln,n.fond,n.date,n.acc, max(s.date) dp from @accstm_n n, AccState s where n.bln=s.bln and n.fond=s.fond -- выборка дат предыдущих движений and n.acc=s.acc -- для счетов с недостающими остатками and n.date>s.date group by n.bln,n.fond,n.date,n.acc update @accstm_n set s=s.s -- вычисление остатков from @accstm_n n, AccState s, @accstm_v v where n.bln=v.bln and n.fond=v.fond and n.acc=v.acc and n.date=v.date and v.bln=s.bln and v.fond=s.fond and v.acc=s.acc and v.dp=s.date insert AccState(bln,fond,date, acc,dt,cr,s) select bln,fond,date,acc,0,0,s -- вставка недостающих состояний from @accstm_n -- счетов update AccState -- пересчет остатков set s=a.s+s.s from AccState a, @accstm_s s where a.bln=s.bln and a.fond=s.fond and a.acc=s.acc and a.date>=s.date1 and a.date<s.date2 update AccState -- пересчет оборотов set dt=dt+d, cr=cr+c from AccState a, @accstm_p p where p.bln=a.bln and p.fond=a.fond and p.acc=a.acc and a.date=p.date and p.date<>'20651031' delete AccState -- удаление ненужных состояний from AccState a, @accstm_p p where p.bln=a.bln and p.fond=a.fond and p.acc=a.acc and a.date=p.date and p.date<>'20651031' and cr=0 and dt=0 Понимаю что разбираться в таком количестве лень. Суть в том что данные последовательно обрабатываются и в конце используются для модификации рабочих таблиц. При чем используются не по одному разу. Кое-какие запросы можно было бы объеденить через UNION. Но если объединять очень много - читабельность падает. Наверняка нечто подобное(последовательная обработка) приходится делать и на Оракле. Как это обычно делается? Где хранятся промежуточные результаты? Насчет глобальных таблиц - я их использую только в одном случае: допустим когда чего-то понасчитал в обычные временные таблицы, а потом надо это получить в Эксель. Проще всего это сделать через GTT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:07 |
|
||
|
|

start [/forum/topic.php?fid=35&fpage=44&tid=1553899]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
17ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 319ms |

| 0 / 0 |
