Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию / PostgreSQL

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

17 сообщений из 92, страница 4 из 4

все

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083420

O_79_O

Гость

сделал без аналайза ну и собственно результат на лицо
этот запрос из консоли выдает результат за почти 7 секунд

...

Рейтинг:

0 / 0

12.07.2021, 17:52

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083421

O_79_O

Гость

СОбственно теперь вопрос к знатокам - есть ли какие то способы убыстрить count(*)
( судя по всему нет - я почитал доки постгреса)
и если так ,то может можно как то достать общее количество из первого запроса который выглядит вот так

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.

select p.*
from respondent p
where exists(select from respondent_channel rc where p.id = rc.respondent_id and rc.channel_type = 'EMAIL')
  and exists(select from respondent_channel rc where p.id = rc.respondent_id and rc.channel_type = 'SMS')
  and exists(select from respondent_channel rc where p.id = rc.respondent_id and rc.channel_type = 'PUSH')
  and p.space_id = 1
  and p.deleted_at is null
limit 12 offset 0

...

Рейтинг:

0 / 0

12.07.2021, 18:00

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083431

O_79_O

Гость

причем count так плохо работает только с этим запросом ,
напрмер с полнотектовым поиском он за 500 мс

Код: plsql

1.
2.
3.
4.
5.
6.
7.

select count(*)
from respondent p
where to_tsvector('russian',
                  coalesce(first_name, '') || ' ' || coalesce(last_name, '') || ' ' || coalesce(patronymic, '') ||
                  ' ' || email) @@ plainto_tsquery('russian', 'Петр')
  and p.space_id = 1
  and p.deleted_at is null

...

Рейтинг:

0 / 0

12.07.2021, 18:39

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083438

O_79_O

Гость

таже самая участь стала и селектом на интерсетах

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.

select count(1) from respondent p where p.id in (
  select pc.respondent_id from respondent_channel pc where pc.channel_type ='EMAIL'
  intersect all
  select pc.respondent_id from respondent_channel pc where pc.channel_type = 'SMS'
  intersect all
  select pc.respondent_id from respondent_channel pc where pc.channel_type ='PUSH')
and p.space_id=1
and p.deleted_at is null ;

теже самые 6.5-7 секунд

...

Рейтинг:

0 / 0

12.07.2021, 19:09

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083447

O_79_O

Гость

я так понимаю единственный вменяемый по скорости способ получить количество элементов можно лишь распарсив план ,но там есть допуск около 1%

...

Рейтинг:

0 / 0

12.07.2021, 22:06

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083454

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

O_79_O

там допуск и 100% может быть...
это как база себе представляет... что может сильно с реальностью расходится.

Например есть у вас миллион respondent и есть по 500.000 SMS и 500.000 PUSH
база будет предполагать что распределение случайное и соотвественно тех у кого и sms и push есть 250.000
а в реальности их может быть и 0 (у половины только sms а у второй половины только push)
и 500.000 (у 500.000 и SMS и PUSH у вторых 500.000 - ничего).
В обоих случаях explain вам 250.000 ожидаемых строк вернёт.

Так что у этого метода много ограничений и подводных камней.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

...

Рейтинг:

0 / 0

12.07.2021, 22:41

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083457

O_79_O

Гость

Maxim Boguk

O_79_O

понял ,спасибо за совет)
а что тогда пагинация на постгресе в своем классическом исполнении не возможна получается?

...

Рейтинг:

0 / 0

12.07.2021, 22:57

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083458

O_79_O

Гость

попробовал и такой варинат

Код: plsql

1.
2.
3.
4.

 select p.* ,count(*) over() as total_count 
from respondent p
 where....
limit 12

2.3 секунды но тоже никуда не годится конечно

...

Рейтинг:

0 / 0

12.07.2021, 23:00

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083460

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

O_79_O

Maxim Boguk

пропущено...

там допуск и 100% может быть...
это как база себе представляет... что может сильно с реальностью расходится.

Например есть у вас миллион respondent и есть по 500.000 SMS и 500.000 PUSH
база будет предполагать что распределение случайное и соотвественно тех у кого и sms и push есть 250.000
а в реальности их может быть и 0 (у половины только sms а у второй половины только push)
и 500.000 (у 500.000 и SMS и PUSH у вторых 500.000 - ничего).
В обоих случаях explain вам 250.000 ожидаемых строк вернёт.

Так что у этого метода много ограничений и подводных камней.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

А она ни на какой базе не возможна на хоть сколько то разумных обьемах...
count(*) по 1.000.000 будет работать ВСЕГДА приблизително столько же сколько select * по этим же миллионам строк (и никакая база вам это не ускорит).
Потому что 90% времени это найти нужные вам строки а подсчитать их или отдать как есть - в пределах погрешности.

Более того - никто уже не делает пагинацию больше чем на 5-10 страниц потому что это просто никому не нужно в реальности.
Ну вот будет у вас пагинация на 10000 страниц... вот кому и какая прикладная для этого польза?

Особенно учитывая тот милый факт (про который алогеты "пагинация на постгресе в своем классическом исполнении" не помнят) что она никогда не будет корректно работать на базе в которой идёт запись в используемые в запросе таблицы.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

...

Рейтинг:

0 / 0

12.07.2021, 23:31

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083461

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

O_79_O

таже самая участь стала и селектом на интерсетах

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.

select count(1) from respondent p where p.id in (
  select pc.respondent_id from respondent_channel pc where pc.channel_type ='EMAIL'
  intersect all
  select pc.respondent_id from respondent_channel pc where pc.channel_type = 'SMS'
  intersect all
  select pc.respondent_id from respondent_channel pc where pc.channel_type ='PUSH')
and p.space_id=1
and p.deleted_at is null ;

теже самые 6.5-7 секунд

Что вполне ожидаемо потому что количество строк к пересчёту округлённо тоже самое или даже выше тут.

...

Рейтинг:

0 / 0

12.07.2021, 23:32

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083463

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

O_79_O

причем count так плохо работает только с этим запросом ,
напрмер с полнотектовым поиском он за 500 мс

Код: plsql

1.
2.
3.
4.
5.
6.
7.

select count(*)
from respondent p
where to_tsvector('russian',
                  coalesce(first_name, '') || ' ' || coalesce(last_name, '') || ' ' || coalesce(patronymic, '') ||
                  ' ' || email) @@ plainto_tsquery('russian', 'Петр')
  and p.space_id = 1
  and p.deleted_at is null

Так тут строк намного меньше обрабатывать в процессе надо.
count(*) с итогом в 1000.000 вероятнее всего будет не менее чем в 1000 раз медленее чем count(*) с итогом в 1000
если запрос одной структуры.
Это не count(*) плохо работает а запрос на выборку сложную 300.000 строк не быстрый выходит.

Я бы еще включил track_io_timing в конфиге и делал бы explain (analyze,costs,buffers,timing) запросов
может у вас 3/4 времени работа с диском занимает и тогда просто базе надо больше памяти будет выдать и все ускорится заметно.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

...

Рейтинг:

0 / 0

12.07.2021, 23:36

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083466

O_79_O

Гость

Maxim Boguk,
включил в конфигах что вы сказали

Код: plsql

1.
2.
3.
4.
5.
6.
7.

explain (analyze,costs,buffers,timing)
select count(*) from respondent p
where exists(select from respondent_channel rc where p.id = rc.respondent_id and rc.channel_type = 'EMAIL')
  and exists(select from respondent_channel rc where p.id = rc.respondent_id and rc.channel_type = 'SMS')
  and exists(select from respondent_channel rc where p.id = rc.respondent_id and rc.channel_type = 'PUSH')
  and p.space_id = 1
  and p.deleted_at is null

запрос

аналитика

Код: plsql

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.

Finalize Aggregate  (cost=321825.09..321825.10 rows=1 width=8) (actual time=2868.095..2936.541 rows=1 loops=1)
"  Buffers: shared hit=1744410 read=611001, temp read=5608 written=5744"
  I/O Timings: read=4738.084
  ->  Gather  (cost=321824.87..321825.08 rows=2 width=8) (actual time=2866.772..2936.513 rows=3 loops=1)
        Workers Planned: 2
        Workers Launched: 2
"        Buffers: shared hit=1744410 read=611001, temp read=5608 written=5744"
        I/O Timings: read=4738.084
        ->  Partial Aggregate  (cost=320824.87..320824.88 rows=1 width=8) (actual time=2841.225..2841.229 rows=1 loops=3)
"              Buffers: shared hit=1744410 read=611001, temp read=5608 written=5744"
              I/O Timings: read=4738.084
              ->  Nested Loop  (cost=73937.04..320476.34 rows=139413 width=0) (actual time=423.751..2826.364 rows=111112 loops=3)
"                    Buffers: shared hit=1744410 read=611001, temp read=5608 written=5744"
                    I/O Timings: read=4738.084
                    ->  Nested Loop  (cost=73936.61..209089.50 rows=163592 width=24) (actual time=423.098..1411.921 rows=111112 loops=3)
"                          Buffers: shared hit=815247 read=206822, temp read=5608 written=5744"
                          I/O Timings: read=1704.003
                          ->  Parallel Hash Join  (cost=73936.18..131764.68 rows=151025 width=16) (actual time=422.422..590.180 rows=111112 loops=3)
                                Hash Cond: (rc_1.respondent_id = rc_2.respondent_id)
"                                Buffers: shared hit=73 read=21986, temp read=5608 written=5744"
                                I/O Timings: read=348.839
                                ->  Parallel Bitmap Heap Scan on respondent_channel rc_1  (cost=11055.91..63468.91 rows=413520 width=8) (actual time=41.168..177.346 rows=333335 loops=3)
                                      Recheck Cond: (channel_type = 'SMS'::text)
                                      Heap Blocks: exact=4135
                                      Buffers: shared hit=2 read=13190
                                      I/O Timings: read=230.265
                                      ->  Bitmap Index Scan on resp_channel_type  (cost=0.00..10807.80 rows=992449 width=0) (actual time=39.600..39.600 rows=1000005 loops=1)
                                            Index Cond: (channel_type = 'SMS'::text)
                                            Buffers: shared hit=2 read=843
                                            I/O Timings: read=9.358
                                ->  Parallel Hash  (cost=58270.27..58270.27 rows=280960 width=8) (actual time=135.766..135.767 rows=222223 loops=3)
                                      Buckets: 131072  Batches: 16  Memory Usage: 2720kB
"                                      Buffers: shared read=8796, temp written=2260"
                                      I/O Timings: read=118.574
                                      ->  Parallel Bitmap Heap Scan on respondent_channel rc_2  (cost=7514.28..58270.27 rows=280960 width=8) (actual time=10.800..77.454 rows=222223 loops=3)
                                            Recheck Cond: (channel_type = 'PUSH'::text)
                                            Heap Blocks: exact=2791
                                            Buffers: shared read=8796
                                            I/O Timings: read=118.574
                                            ->  Bitmap Index Scan on resp_channel_type  (cost=0.00..7345.70 rows=674303 width=0) (actual time=30.813..30.813 rows=666670 loops=1)
                                                  Index Cond: (channel_type = 'PUSH'::text)
                                                  Buffers: shared read=564
                                                  I/O Timings: read=7.725
                          ->  Index Only Scan using respondent_id_channel on respondent_channel rc  (cost=0.43..0.51 rows=1 width=8) (actual time=0.007..0.007 rows=1 loops=333335)
                                Index Cond: ((respondent_id = rc_1.respondent_id) AND (channel_type = 'EMAIL'::text))
                                Heap Fetches: 0
                                Buffers: shared hit=815174 read=184836
                                I/O Timings: read=1355.164
                    ->  Index Scan using respondent_pkey on respondent p  (cost=0.43..0.68 rows=1 width=8) (actual time=0.012..0.012 rows=1 loops=333335)
                          Index Cond: (id = rc.respondent_id)
                          Filter: ((deleted_at IS NULL) AND (space_id = 1))
                          Buffers: shared hit=929163 read=404179
                          I/O Timings: read=3034.081
Planning:
  Buffers: shared hit=358 read=58
  I/O Timings: read=6.354
Planning Time: 13.222 ms
Execution Time: 2936.886 ms

...

Рейтинг:

0 / 0

13.07.2021, 00:08

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083469

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

O_79_O,

ну вот 1)у вас оно мало того что временные файлы пишет
так ещё и большую часть времени запроса читает данные с диска.

Хотите быстрее
1)ставим work_mem в 32MB
2)ставим shared_buffers в 2GB хотя бы (я надеюсь что у вас локально 8GB хотя бы есть.. если есть 16GB то 4GB shared buffers)
3)ставим random_page_cost=1.1
4)перезапускаем базу
5)делает этот же самый explain (analyze,costs,buffers,timing) не 1 раз а раза 3-4 пока время выполенения не перестанет меняться.
Смотрим какое время получилось.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

...

Рейтинг:

0 / 0

13.07.2021, 00:48

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083471

O_79_O

Гость

Maxim Boguk

спасибо большее буду пробовать ,завтра отпишусь что вышло

...

Рейтинг:

0 / 0

13.07.2021, 01:08

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083614

O_79_O

Гость

Maxim Boguk,большое спасибо за советы- вообщем стало быстрее где то раза в два раза.ПРактически влез в SLA

Код: plsql

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.

Finalize Aggregate  (cost=211449.40..211449.41 rows=1 width=8) (actual time=1069.829..1096.667 rows=1 loops=1)
  Buffers: shared hit=1372056
  ->  Gather  (cost=211449.18..211449.39 rows=2 width=8) (actual time=1066.905..1096.656 rows=3 loops=1)
        Workers Planned: 2
        Workers Launched: 2
        Buffers: shared hit=1372056
        ->  Partial Aggregate  (cost=210449.18..210449.19 rows=1 width=8) (actual time=1037.757..1038.375 rows=1 loops=3)
              Buffers: shared hit=1372056
              ->  Nested Loop  (cost=69833.31..210100.65 rows=139413 width=0) (actual time=360.884..1028.385 rows=111112 loops=3)
                    Buffers: shared hit=1372056
                    ->  Parallel Hash Join  (cost=69832.88..126393.89 rows=163592 width=24) (actual time=360.858..698.457 rows=111112 loops=3)
                          Hash Cond: (rc.respondent_id = rc_1.respondent_id)
                          Buffers: shared hit=38714
                          ->  Parallel Index Only Scan using respondent_id_channel on respondent_channel rc  (cost=0.43..52754.92 rows=833305 width=8) (actual time=0.518..131.214 rows=666670 loops=3)
                                Index Cond: (channel_type = 'EMAIL'::text)
                                Heap Fetches: 0
                                Buffers: shared hit=15332
                          ->  Parallel Hash  (cost=67944.64..67944.64 rows=151025 width=16) (actual time=359.555..360.145 rows=111112 loops=3)
                                Buckets: 524288  Batches: 1  Memory Usage: 19776kB
                                Buffers: shared hit=23314
                                ->  Parallel Hash Join  (cost=31651.40..67944.64 rows=151025 width=16) (actual time=119.127..321.695 rows=111112 loops=3)
                                      Hash Cond: (rc_1.respondent_id = rc_2.respondent_id)
                                      Buffers: shared hit=23314
                                      ->  Parallel Index Scan using respondent_channel_channel_type on respondent_channel rc_1  (cost=0.43..35208.18 rows=413520 width=8) (actual time=0.059..78.276 rows=333335 loops=3)
                                            Index Cond: (channel_type = 'SMS'::text)
                                            Buffers: shared hit=14022
                                      ->  Parallel Hash  (cost=28138.97..28138.97 rows=280960 width=8) (actual time=117.656..117.657 rows=222223 loops=3)
                                            Buckets: 1048576  Batches: 1  Memory Usage: 34304kB
                                            Buffers: shared hit=9292
                                            ->  Parallel Index Scan using respondent_channel_channel_type on respondent_channel rc_2  (cost=0.43..28138.97 rows=280960 width=8) (actual time=0.202..50.994 rows=222223 loops=3)
                                                  Index Cond: (channel_type = 'PUSH'::text)
                                                  Buffers: shared hit=9292
                    ->  Index Scan using respondent_pkey on respondent p  (cost=0.43..0.51 rows=1 width=8) (actual time=0.003..0.003 rows=1 loops=333335)
                          Index Cond: (id = rc.respondent_id)
                          Filter: ((deleted_at IS NULL) AND (space_id = 1))
                          Buffers: shared hit=1333342
Planning:
  Buffers: shared hit=258
Planning Time: 14.422 ms
Execution Time: 1097.360 ms

...

Рейтинг:

0 / 0

13.07.2021, 17:24

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083619

O_79_O

Гость

Максим еще один вопрос хотел спросить,для сортировки по фио я создал вот такой индекс

Код: plsql

create index if not exists fio_respondent on respondent(first_name,last_name,patronymic);

и так же есть индекс

Код: plsql

1.
2.
3.
4.
5.
6.

create index if not exists full_text_search_respondent_gin
  on respondent
  using GIN (to_tsvector('russian', coalesce(first_name, '')
            || ' ' || coalesce(last_name, '')
            || ' ' || coalesce(patronymic, '')
            || ' ' || email));

так вот если я делаю такой запрос

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.

select p.*
from respondent p
where to_tsvector('russian',
                  coalesce(first_name, '') || ' ' || coalesce(last_name, '') || ' ' || coalesce(patronymic, '') ||
                  ' ' || email) @@ plainto_tsquery('russian', 'Петров')
  and p.space_id = 1
  and p.deleted_at is null
order by first_name,last_name,patronymic DESC
limit 12

не будет ли битри индекс fio_respondent мешать полнотекстовому поиску для которого у меня gin index
full_text_search_respondent_gin

аналитика по этому запросу

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

Limit  (cost=75.18..911.88 rows=12 width=276) (actual time=10.302..10.304 rows=12 loops=1)
  Buffers: shared hit=962
  ->  Incremental Sort  (cost=75.18..697324.05 rows=10000 width=276) (actual time=10.300..10.301 rows=12 loops=1)
"        Sort Key: first_name, last_name, patronymic DESC"
"        Presorted Key: first_name, last_name"
        Full-sort Groups: 1  Sort Method: top-N heapsort  Average Memory: 31kB  Peak Memory: 31kB
        Buffers: shared hit=962
        ->  Index Scan using fio_respondent on respondent p  (cost=0.55..696897.15 rows=10000 width=276) (actual time=4.751..10.111 rows=37 loops=1)
"              Filter: ((deleted_at IS NULL) AND (space_id = 1) AND (to_tsvector('russian'::regconfig, ((((((COALESCE(first_name, ''::text) || ' '::text) || COALESCE(last_name, ''::text)) || ' '::text) || COALESCE(patronymic, ''::text)) || ' '::text) || email)) @@ '''петр'''::tsquery))"
              Rows Removed by Filter: 917
              Buffers: shared hit=962
Planning:
  Buffers: shared hit=1
Planning Time: 0.228 ms
Execution Time: 10.331 ms

...

Рейтинг:

0 / 0

13.07.2021, 17:49

| Ответить | Цитировать | Написать

Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию

#40083647

O_79_O

Гость

я так понимаю это опять сложная тема,так как то что я смог нарыть говорит о том ,что слон вроде и может использовать несколько индексов в одном query но только в булевом выражении,что означает ,что если я хочу полнотекст по gin а сортировку по b tree такое не получится
но в любом случае когда считается count(*) используется именно gin это хорошо
когда поиск с лимитом используется btree
когда поиск без лимит планировщик опять использует gin
исходя из этого я предполагаю что эти индексы друг другу не мешают,планировщик сам выберет нужный в зависимости от ситуации

...

Рейтинг:

0 / 0

13.07.2021, 19:41

| Ответить | Цитировать | Написать

17 сообщений из 92, страница 4 из 4

все

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=53&msg=40083454&tid=1993940]:	0ms
get settings:	11ms
get forum list:	14ms
check forum access:	4ms
check topic access:	4ms
track hit:	31ms
get topic data:	11ms
get forum data:	3ms
get page messages:	52ms
get tp. blocked users:	1ms
others:	14ms

total:	145ms