|
|
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
имеется таблица с более 20 млн записями name (text). date(datetime) надо выбрать значение name которые встречаются БОЛЕЕ 1 РАЗА В НЕДЕЛЮ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2016, 13:52 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Примерно так: CREATE TABLE worktime ( name text, dt timestamp with time zone ) WITH ( OIDS=FALSE ); ALTER TABLE worktime OWNER TO postgres; select name,count(extract(week from dt)) from worktime group by name,extract(week from dt) having count(extract(week from dt))>1 PS. я только учусь. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2016, 14:14 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2016, 14:14 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Maxim BogukPerederiy, Для начала определите понятие недели. -- Maxim Boguk www.postgresql-consulting.ru понедельник-воскресенье ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2016, 14:27 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
fortress, На 20 млн. данных Тс рискует не дождаться результата выполнения запроса. Возможно, логичнее было бы использовать [not]exists-подзапрос или самообъединение таблицы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2016, 20:15 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Щукина Аннаfortress, На 20 млн. данных Тс рискует не дождаться результата выполнения запроса. Возможно, логичнее было бы использовать [not]exists-подзапрос или самообъединение таблицы... если узкая таблица из двух полей - вполне фулскан справиться. А вот джоин сам на себя приведет только к двуктратному ухудшению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2016, 10:48 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Ivan DurakЩукина Аннаfortress, На 20 млн. данных Тс рискует не дождаться результата выполнения запроса. Возможно, логичнее было бы использовать [not]exists-подзапрос или самообъединение таблицы... если узкая таблица из двух полей - вполне фулскан справиться. А вот джоин сам на себя приведет только к двуктратному ухудшению.а агрегаты бесплатно деются, ага де'биллы, ять. какой нахер джойн, если есть индекс, по которому сиком можно проверить наличие в диапазоне ? де'биллы, ять. тут ещё икстендер такой пасётся -- чуть что чушь несёт про "двойное обращение к таблице" де'билл, ять. при малости числа name относительно этих 20 лямов -- задача вообще вырождается в пародию на луз--индекскан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2016, 11:12 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
qwwqIvan Durakпропущено... если узкая таблица из двух полей - вполне фулскан справиться. А вот джоин сам на себя приведет только к двуктратному ухудшению.а агрегаты бесплатно деются, ага де'биллы, ять. какой нахер джойн, если есть индекс, по которому сиком можно проверить наличие в диапазоне ? де'биллы, ять. тут ещё икстендер такой пасётся -- чуть что чушь несёт про "двойное обращение к таблице" де'билл, ять. при малости числа name относительно этих 20 лямов -- задача вообще вырождается в пародию на луз--индекскан. сколько у тебя сиков будет? 20 лямов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2016, 16:42 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Ivan Durakqwwqпропущено... при малости числа name относительно этих 20 лямов -- задача вообще вырождается в пародию на луз--индекскан. сколько у тебя сиков будет? 20 лямов? вам какую аценку, радной? пессимистическую --- вы само сделало , только 2--ку забыло. оптимистическая -- count(DISTINCT name) *2 обе оценки тривиальны. но истина -- она где--то между, ага. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2016, 23:20 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
qwwqIvan Durakпропущено... сколько у тебя сиков будет? 20 лямов? вам какую аценку, радной? пессимистическую --- вы само сделало , только 2--ку забыло. оптимистическая -- count(DISTINCT name) *2 обе оценки тривиальны. но истина -- она где--то между, ага. оптимистическая неверна. Если у тебя даже 1 товар всего, но 100500 разных недель.... сиков будет ни разу не два ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2016, 09:37 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
2Дурак учимся читать: Perederiyимеется таблица с более 20 млн записями name (text). date(datetime) надо выбрать значение name которые встречаются БОЛЕЕ 1 РАЗА В НЕДЕЛЮ ни разу не сказано что надо выбрать {имена "и недели"}. т.ч. засуньте своё мнение по адресу произрастания ваших рук. Достаточно чтобы всё сошлось на первой же неделе для каждого имени. точка. // я к тому, что к "коду начинающего" выше по треду надо добавить DISTINCT в исходной постановке, или изменить постановку. (второе так же вероятно, ибо пассажыр известен неточностями. но пока -- решать надо так, как сформулировано). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2016, 10:45 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Щукина Аннаfortress, На 20 млн. данных Тс рискует не дождаться результата выполнения запроса. Возможно, логичнее было бы использовать [not]exists-подзапрос или самообъединение таблицы... Никак не могу придумать такой запрос с предикатом exists: он же true когда что-то есть в подзапросе и false - когда ничего нет. А здесь условие чтобы количество в неделю было больше одного. Или имелось ввиду в подзапросе для exist считать количество попаданий в неделю? Тогда чем это лучше group by/having? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2016, 13:27 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
fortressЩукина Аннаfortress, На 20 млн. данных Тс рискует не дождаться результата выполнения запроса. Возможно, логичнее было бы использовать [not]exists-подзапрос или самообъединение таблицы... Никак не могу придумать такой запрос с предикатом exists: он же true когда что-то есть в подзапросе и false - когда ничего нет. А здесь условие чтобы количество в неделю было больше одного. Или имелось ввиду в подзапросе для exist считать количество попаданий в неделю? Тогда чем это лучше group by/having? для простоты, чтобы не реализовывать loose--indexscan руками, представим, что у вас есть головная [reference] таблица names тогда запрос ~ Код: sql 1. 2. 3. 4. зачем вам весь каунт (да ещё по всем неделям), когда вас интересует наличие [не менее] 2--х (хоть в какой--то неделе) ? в случае отсутствия -- первый экзист солется в экстазе с WITH recursive реализацией loose indexscan--а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2016, 13:45 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
qwwqfortressпропущено... Никак не могу придумать такой запрос с предикатом exists: он же true когда что-то есть в подзапросе и false - когда ничего нет. А здесь условие чтобы количество в неделю было больше одного. Или имелось ввиду в подзапросе для exist считать количество попаданий в неделю? Тогда чем это лучше group by/having? для простоты, чтобы не реализовывать loose--indexscan руками, представим, что у вас есть головная [reference] таблица names тогда запрос ~ Код: sql 1. 2. 3. 4. зачем вам весь каунт (да ещё по всем неделям), когда вас интересует наличие [не менее] 2--х (хоть в какой--то неделе) ? в случае отсутствия -- первый экзист солется в экстазе с WITH recursive реализацией loose indexscan--а. план если не лень будет проверю, но имхо там фулскан на первом же экзисте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2016, 12:02 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Попробовал 2 способами: через exist и через having. Таблица (индексов по полям нет): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Запрос 1: Код: sql 1. 2. 3. 4. План: "GroupAggregate (cost=147906.84..180406.84 rows=1000000 width=18) (actual time=11305.775..15200.587 rows=146 loops=1)" " Group Key: num, (date_part('week'::text, dt)), (date_part('year'::text, dt))" " Filter: (count((date_part('week'::text, dt))) > 1)" " Rows Removed by Filter: 999708" " -> Sort (cost=147906.84..150406.84 rows=1000000 width=18) (actual time=11301.042..14561.973 rows=1000000 loops=1)" " Sort Key: num, (date_part('week'::text, dt)), (date_part('year'::text, dt))" " Sort Method: external merge Disk: 48784kB" " -> Seq Scan on tlog (cost=0.00..27739.00 rows=1000000 width=18) (actual time=26.221..1149.959 rows=1000000 loops=1)" "Planning time: 0.092 ms" "Execution time: 15208.465 ms" Код: sql 1. 2. Запрос 2: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. План: "Hash Semi Join (cost=41099.00..84418.00 rows=1 width=10) (actual time=789.367..2305.005 rows=146 loops=1)" " Hash Cond: (t1.num = t2.num)" " Join Filter: ((t2.id <> t1.id) AND (t2.dt > t1.dt) AND (((date_part('year'::text, t1.dt) * date_part('week'::text, t1.dt)) - (date_part('year'::text, t2.dt) * date_part('week'::text, t2.dt))) = 0::double precision))" " Rows Removed by Join Filter: 1057103" " -> Seq Scan on tlog t1 (cost=0.00..22739.00 rows=1000000 width=22) (actual time=26.454..240.050 rows=1000000 loops=1)" " -> Hash (cost=22739.00..22739.00 rows=1000000 width=22) (actual time=682.298..682.298 rows=1000000 loops=1)" " Buckets: 16384 Batches: 16 Memory Usage: 2953kB" " -> Seq Scan on tlog t2 (cost=0.00..22739.00 rows=1000000 width=22) (actual time=25.716..234.652 rows=1000000 loops=1)" "Planning time: 0.357 ms" "Execution time: 2306.248 ms" Код: sql 1. 2. Запросы выполнялись один за другим (несколько раз), поэтому кеш тоже как-то оказвает влияние. Про использование exist сразу не додумался, но qwwq подсказал, в результате получился второй запрос. На что нужно обратить внимание: группировать нужно еще и по годам, т.к. номер недели будет уникальным только в пределах одного года; записи на границе годов; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2016, 11:39 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
ну добавь индекс то по наме+дата ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2016, 15:11 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Добавил индексы Код: 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. 29. 30. Результаты не сильно изменились. Код: sql 1. 2. 3. 4. "GroupAggregate (cost=163030.96..195531.00 rows=1000001 width=17) (actual time=9287.012..11121.720 rows=154 loops=1)" " Filter: (count((date_part('week'::text, dt))) > 1)" " -> Sort (cost=163030.96..165530.97 rows=1000001 width=17) (actual time=9277.208..10654.634 rows=1000005 loops=1)" " Sort Key: num, (date_part('week'::text, dt)), (date_part('year'::text, dt))" " Sort Method: external merge Disk: 48856kB" " -> Seq Scan on tlog (cost=0.00..22353.02 rows=1000001 width=17) (actual time=0.063..801.386 rows=1000005 loops=1)" "Total runtime: 11129.723 ms" Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. "Hash Semi Join (cost=35713.02..74146.04 rows=1 width=9) (actual time=1167.768..3047.378 rows=154 loops=1)" " Hash Cond: ((t1.num)::text = (t2.num)::text)" " Join Filter: ((t2.id <> t1.id) AND (t2.dt > t1.dt) AND (((date_part('year'::text, t1.dt) * date_part('week'::text, t1.dt)) - (date_part('year'::text, t2.dt) * date_part('week'::text, t2.dt))) = 0::double precision))" " -> Seq Scan on tlog t1 (cost=0.00..17353.01 rows=1000001 width=21) (actual time=0.062..216.557 rows=1000005 loops=1)" " -> Hash (cost=17353.01..17353.01 rows=1000001 width=21) (actual time=1011.997..1011.997 rows=1000005 loops=1)" " Buckets: 2048 Batches: 64 Memory Usage: 870kB" " -> Seq Scan on tlog t2 (cost=0.00..17353.01 rows=1000001 width=21) (actual time=0.004..211.858 rows=1000005 loops=1)" "Total runtime: 3047.731 ms" Похоже что индексы не используются, т.к. в планах оcтался Seq Scan. Ведь должен быть Index Scan? Это такие запросы, которые не могут использовать индексы, или такие индексы, которые не могут быть использованы в этих запросах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 22:29 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
fortress<> Это такие запросы, которые не могут использовать индексы, или такие индексы, которые не могут быть использованы в этих запросах?и то и другое для нахождения существования второго факта в пределах недели от первого нет нужды сначала множится на все факты отличные от текущего , а потом фильтровать по заумным функциональным выражениям. достаточно посмотреть на следующий факт вдоль подходящего индекса в диапазоне не более 8 дней и убедиться в том , что он не вывалился из нашей недели. или наоборот -- вывалился. как--то так. подходящим будет составной индекс по нейму и дате, и именно в таком порядке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 23:39 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
или что следующего, в пределе 8 дней, -- нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 23:47 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
qwwqдля нахождения существования второго факта в пределах недели от первого нет нужды сначала множится на все факты отличные от текущего , а потом фильтровать по заумным функциональным выражениям. достаточно посмотреть на следующий факт вдоль подходящего индекса в диапазоне не более 8 дней и убедиться в том , что он не вывалился из нашей недели. или наоборот -- вывалился. ТС вроде обмолвился что неделя у него это понедельник-воскресенье, как я понял календарная неделя. Если разница межу 2 событиями менее 8 дней, то это не значит, что они в пределах одной и той же календарной недели. В моей тестовой БД из 1 млн. строк записи за несколько лет, поэтому приходится учитывать ещё и год. Отсюда такое выражение. Можно, конечно, и так переписать: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. qwwqподходящим будет составной индекс по нейму и дате, и именно в таком порядке. Попробовал создать индекс: Код: sql 1. 2. 3. 4. Для этого Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. запроса в плане отсутствует упоминание об использовании индексов: "Sort (cost=74146.19..74146.19 rows=1 width=17) (actual time=26468.490..26468.496 rows=154 loops=1)" " Sort Key: t1.dt" " Sort Method: quicksort Memory: 37kB" " -> Hash Semi Join (cost=35713.11..74146.18 rows=1 width=17) (actual time=10368.299..26468.155 rows=154 loops=1)" " Hash Cond: ((t1.num)::text = (t2.num)::text)" " Join Filter: ((t2.id <> t1.id) AND (t2.dt > t1.dt) AND (((date_part('year'::text, t1.dt) * date_part('week'::text, t1.dt)) - (date_part('year'::text, t2.dt) * date_part('week'::text, t2.dt))) = 0::double precision))" " -> Seq Scan on tlog t1 (cost=0.00..17353.05 rows=1000005 width=21) (actual time=0.031..220.269 rows=1000005 loops=1)" " -> Hash (cost=17353.05..17353.05 rows=1000005 width=21) (actual time=10172.847..10172.847 rows=1000005 loops=1)" " Buckets: 2048 Batches: 64 Memory Usage: 870kB" " -> Seq Scan on tlog t2 (cost=0.00..17353.05 rows=1000005 width=21) (actual time=0.004..211.227 rows=1000005 loops=1)" "Total runtime: 26468.760 ms" Также время выполнения запроса выросло в 10 раз со вчерашнего дня, с чем связано - не знаю. Пробовал созданный индекс удалять - не помогло. Больше с базой ничего не делал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2016, 23:37 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
fortressqwwqдля нахождения существования второго факта в пределах недели от первого нет нужды сначала множится на все факты отличные от текущего , а потом фильтровать по заумным функциональным выражениям. достаточно посмотреть на следующий факт вдоль подходящего индекса в диапазоне не более 8 дней и убедиться в том , что он не вывалился из нашей недели. или наоборот -- вывалился. ТС вроде обмолвился что неделя у него это понедельник-воскресенье, как я понял календарная неделя. Если разница межу 2 событиями менее 8 дней, то это не значит, что они в пределах одной и той же календарной недели. я не совсем понимаю, вы прикидываетесь, или всё действительно так плохо. ещё раз , добавьте условие , что следующее искомое ищется в диапазоне не более 8 дней. И (AND) какое угодно замысловатое условие фильтра на вашу любимую "ту же неделю". условие про 8 дней нужно чтобы обрезать оптимайзеру область поиска. и счета вы же не думаете, что у ней унутре неонка и думатель. вот чтобы 20 миллионов раз не молотить чиселки в холостую, а до того -- не читать их с диска или кеша -- обрежьте, ять, вдоль индекса. (там, при прямой навигации нужен один seek и проверка -- и всё, больше там ничего не надо) что-то типа Код: sql 1. ну и вообще говоря у меня нет уверенности, что если мы таки не вернемся к тому, что в постановке не требуется выводить нейм столько раз , сколько подходящих недель -- то полуцчим реальный выигрыш. но это отдельный разговор про with recursive реализацию loose indexscan--а. и оценки распределения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 01:18 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
qwwq, а делать индех по EXTRACT(WEEK FROM timestampfield); и делать поиск недели по этому выражению? не? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 07:37 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
Lonepsychoqwwq, а делать индех по EXTRACT(WEEK FROM timestampfield); и делать поиск недели по этому выражению? не?ыыыЫ? кю повторяю: вам надо посмотреть на первый лист индекса , обычного индекса по таймтстампу, и всё. никакого поиска недели не надо. лист либо лежит в той же неделе, либо не судьба. и тогда это превратится в 20 лямов сиков, как метко заметил Ваня дурак. а вот когда мы заметим, что мы имя выводим столько раз , сколько таких недель, а нас просили вывести один -- вот тогда начнётся (от распределения) экономия. если сумеем аккуратно записать обход с отбрасыванием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 08:34 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
qwwqповторяю: вам надо посмотреть на первый лист индекса , обычного индекса по таймтстампу, и всё. никакого поиска недели не надо. лист либо лежит в той же неделе, либо не судьба. и тогда это превратится в 20 лямов сиков, как метко заметил Ваня дурак. а вот когда мы заметим, что мы имя выводим столько раз , сколько таких недель, а нас просили вывести один -- вот тогда начнётся (от распределения) экономия. если сумеем аккуратно записать обход с отбрасыванием. я это понял, но идея была не искать существуют ли даты на дистанции 8 дней, а искать существуют ли даты попадающие в одну и ту же самую неделю (более дёшиво чтоли). однако да. ф-я week работает в пределах одного года (и в пересечениях лет), и, результат не является уникальным для епохи. так что может идея и не правильная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 08:42 |
|
||
|
Помогите с запросом - сколько раз в неделю
|
|||
|---|---|---|---|
|
#18+
подытожу, о чём примерно шла речь: подготовка кейса DDL: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. --DATA: Код: 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. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. планы : GROUP Код: sql 1. 2. 3. 4. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. //на distinct забиваем LOOSE--INDEXSCAN Код: 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. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. Код: 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. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. резюме : при count(distinct name) < 1/2000 от count(1) имеет смысл LOOSE indexscan. (время у него, навскидку, в этой задаче зависит от распределения, а минимум -- только от этого отношения -- для каждого нейм -- 2 сика. и либо пан, либо нет. если же распределение хуже -- число сиков будет расти с переходом в пределе к пресловутым "20 лямам"*2) ну а реальная ширина таблицы [если в ней много больше 2--х полей] добавит преимуществ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2016, 14:18 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=93&tid=1997280]: |
0ms |
get settings: |
9ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
66ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 427ms |

| 0 / 0 |
