Гость
Войти | Профиль | Очистить
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Постгре начинает тормозить на запросе при пороговом значении limit / 25 сообщений из 31, страница 1 из 2
  1  все
26.07.2018, 10:08
    #39679433
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Коллеги, доброе утро.
По Постгре опыт не сильно большой. Базовые настройки менял, запросы оптимизировал.
Но вот наткнулись на такой ньюанс.
СУБД на Windows.

Есть линейный запрос:
Код: sql
1.
Select * from Table limit X



Ставим вместо х 10.000, запрос работает 10с.
20.000 - 20с.
и т.д., все вроде бы линейно.
Но по достижению какого-то порогового значения, допустим, 60.000, запрос выполняется ну там 1.5 минуты.
После этого запрос на 10.000 начинает работать дольше, 18с.

Через какое-то время все запросы снова выполняются за стандартное время.
Не очень понятно, что происходит. Может я не до конца понимаю, как работает буфер данных в Постгре...

Проверяли все это на продакшн сервере на виртуалке, на тестовом сервере на другой виртуалке, и даже на локальном физическом сервере.
На 2х виртуалках с разными ресурсами(32 на тестовом и 57 на продакшн гб) по памяти наблюдали данный эффект. На локальном физическом сервере такого эффекта не наблюдали, но там данных было всего 41.000.

Памяти вроде достаточно. На тестовом в Shared_buffers указано 6гб, на продакшн поднимали с 6 до 12, никакого эффекта не достигнули.
Или дело может быть в виртуалках? При тестировании всех и все отключали. На тестовом так точно никого не нет
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 10:40
    #39679461
mefman
mefman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
MegabyteПо Постгре опыт не сильно большой. Базовые настройки менял, запросы оптимизировал.

Это такой замкадский диалект?
типа поребрика, шавермы итд?
СУБД называется PostgreSQL, допустимо называть Постгрес, на не как не что-то другое
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 11:01
    #39679474
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
mefmanMegabyteПо Постгре опыт не сильно большой. Базовые настройки менял, запросы оптимизировал.

СУБД называется PostgreSQL, допустимо называть Постгрес, на не как не что-то другое
Принято. :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 11:24
    #39679487
Melkij
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Megabyte,

смотрите для начала explain (analyze, buffers) при включенном в конфиге track_io_timing.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 11:24
    #39679489
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Megabyte,

Приведите `EXPLAIN (analyze, buffers)` для запросов с интересующими значениями X, будет проще показать.

Однако, использовать столь большие значения для LIMIT да ещё и без ORDER BY — сильный анти-паттерн.
Какую задачу пытаетесь решить?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 12:11
    #39679531
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
vyegorovMegabyte,

Однако, использовать столь большие значения для LIMIT да ещё и без ORDER BY — сильный анти-паттерн.
Какую задачу пытаетесь решить?
Как таковой задачи нет. Просто клиент на больших объемах заметил такую вот особенность.
В первую очередь для себя хочу разобраться, почему такое поведение.

EXPLAIN (analyze, buffers), да, гляну.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 14:31
    #39679645
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
X = 10.000: время выполнения, 1с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..7184.38 rows=10000 width=2061) (actual time=0.041..294.720 rows=10000 loops=1)"
"  Buffers: shared read=5174"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.039..291.570 rows=10000 loops=1)"
"        Buffers: shared read=5174"
"Planning time: 93.881 ms"
"Execution time: 296.397 ms"



X = 20.000: 3с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..14368.76 rows=20000 width=2061) (actual time=0.010..862.423 rows=20000 loops=1)"
"  Buffers: shared hit=6 read=14243"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.009..855.537 rows=20000 loops=1)"
"        Buffers: shared hit=6 read=14243"
"Planning time: 0.335 ms"
"Execution time: 865.630 ms"



X = 40.000: 6с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..28737.52 rows=40000 width=2061) (actual time=0.009..324.086 rows=40000 loops=1)"
"  Buffers: shared hit=14 read=5633"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.007..313.061 rows=40000 loops=1)"
"        Buffers: shared hit=14 read=5633"
"Planning time: 0.334 ms"
"Execution time: 329.299 ms"



X = 60.000: 9с
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..43106.28 rows=60000 width=2061) (actual time=0.009..459.498 rows=60000 loops=1)"
"  Buffers: shared hit=15 read=7761"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.007..443.212 rows=60000 loops=1)"
"        Buffers: shared hit=15 read=7761"
"Planning time: 0.313 ms"
"Execution time: 467.411 ms"



X = 100.000: 58с, 2й раз 60с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..71843.81 rows=100000 width=2061) (actual time=0.010..3109.619 rows=100000 loops=1)"
"  Buffers: shared hit=3 read=51196"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.009..3078.248 rows=100000 loops=1)"
"        Buffers: shared hit=3 read=51196"
"Planning time: 0.307 ms"
"Execution time: 3124.537 ms"



X = 100.000: 2й раз 60с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..71843.81 rows=100000 width=2061) (actual time=0.009..4814.963 rows=100000 loops=1)"
"  Buffers: shared hit=1 read=79115"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.008..4781.128 rows=100000 loops=1)"
"        Buffers: shared hit=1 read=79115"
"Planning time: 0.337 ms"
"Execution time: 4832.361 ms"



Я так понимаю, что в следующих итерациях PostgreSQL меньше данных читает из буфера.
Почему?

Сделал запрос с явной сортировкой:
Код: sql
1.
select * from skulskul2 order by skul_no limit 100000


Выполнился за 30с, 2й раз за 25с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.43..237660.77 rows=100000 width=2061) (actual time=0.019..275.851 rows=100000 loops=1)"
"  Buffers: shared hit=100685"
"  ->  Index Scan using pk_skulskul2 on skulskul2  (cost=0.43..3606054.11 rows=1517314 width=2061) (actual time=0.017..248.251 rows=100000 loops=1)"
"        Buffers: shared hit=100685"
"Planning time: 0.344 ms"
"Execution time: 288.582 ms"


Прикольно, PostgreSQL заюзал Primary Key и сделал индекс скан вместо сканирования таблицы...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 16:32
    #39679749
Ы2
Ы2
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Megabyte, чем вы свои секунды измеряете? В последнем примере, где вы пишите 60 с, база уверена, что сделала все за 4,8 с.
Если вы смотрите время выполнения в PgAdmin, то он показывает не время выполнения запроса, а суммарное время, потребное в т.ч. на передачу данных и, возможно, отображение.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 17:38
    #39679789
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Ы2Megabyte, чем вы свои секунды измеряете? В последнем примере, где вы пишите 60 с, база уверена, что сделала все за 4,8 с.
Если вы смотрите время выполнения в PgAdmin, то он показывает не время выполнения запроса, а суммарное время, потребное в т.ч. на передачу данных и, возможно, отображение.
Я написал фактическое время, да, когда, собственно, выполнил сам запрос.
А Execution time в explain разве показывает реальное время, а не предполагаемое?
Т.к. запрос с explain - это уже был следующий запрос.

p.s. Т.е., получается, PostgreSQL значительную часть времени может тратить на передачу и отображение, а не выполнение запроса?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 17:42
    #39679793
Leonid Kudryavtsev
Leonid Kudryavtsev
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
MegabyteТ.е., получается, PostgreSQL значительную часть времени может тратить на передачу и отображение, а не выполнение запроса?

НЕ PostgreSQL, а то приложение, которым Вы данные извлекаете.
IMHO & AFAIK
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 17:45
    #39679795
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Megabytep.s. Т.е., получается, PGAdmin значительную часть времени может тратить на передачу и отображение, а не выполнение запроса?
поправил
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 20:35
    #39679869
Melkij
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
MegabyteА Execution time в explain разве показывает реальное время, а не предполагаемое?
explain analyze - именно реальное выполнение запроса. И actual time в каждом узле - реальное измеренное время выполнения этого узла плана от первой до последней строки результата.
Но без учёта передачи ответа по сети, да. Т.к. ответ никуда не передаётся.
И даже Planning time - это не планируемое время, а реальное время затраченное планировщиком запроса на составление и выбор плана выполнения.

При включенном track_io_timing в explain (analyze,buffers) будет ещё измерение времени чтения всех блоков, которые не нашли в shared buffers. Которое тоже может сильно скакать, тем более в вашем случае где судя по explain ничего в shared buffers не было и чуть менее чем всё просили читать операционную систему.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 21:20
    #39679891
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Спасибо.

К слову о реальной задаче.
Есть запрос, без каких либо условий фильтрации. Просто join нескольких таблиц среднего размера(100-300 тысяч записей).
Базовая(первая таблица выборки) таблица, как раз та, по которой возник вопрос насчет Select * from Table limit X.

В MS SQL этот запрос отрабатывает в районе 10с, что в студии, что в приложении.

В PostgreSQL запрос в студии и в приложении работает 70с.
Execution time в explain (analyse, buffers) показывает 15-16с.
Получается, что 55-56с тратится, что в приложении, что в PgAdmin на передачу данных и отображение..?

Это возможно как-то ускорить? Или что на это влияет?

Со слов клиента, раньше этот запрос в приложении работал за 30с(проверить нет возможности), Кол-во данных не менялось.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 21:38
    #39679902
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
MegabyteСпасибо.

К слову о реальной задаче.
Есть запрос, без каких либо условий фильтрации. Просто join нескольких таблиц среднего размера(100-300 тысяч записей).
Базовая(первая таблица выборки) таблица, как раз та, по которой возник вопрос насчет Select * from Table limit X.

В MS SQL этот запрос отрабатывает в районе 10с, что в студии, что в приложении.

В PostgreSQL запрос в студии и в приложении работает 70с.
Execution time в explain (analyse, buffers) показывает 15-16с.
Получается, что 55-56с тратится, что в приложении, что в PgAdmin на передачу данных и отображение..?

Это возможно как-то ускорить? Или что на это влияет?

Со слов клиента, раньше этот запрос в приложении работал за 30с(проверить нет возможности), Кол-во данных не менялось.

Для начала - обновится до 10.4 и включить параллельное выполнение запросов на многих ядрах.
Дальше в psql делать
1)explain (analyze, costs, buffers, timing) запроса общего

2)\timing on
\o somefile
запрос;
чтобы посмотреть на сколько времени запрос выполняется в реальности и главное какой обьем данных он отдает

3)если с временем на приложении сильно не совпадает - смотреть на то какая вообще скорость сети и за какое время этот БОЛЬШОЙ ответ через нее пролезает (вряд ли у вас 10GBit кругом чтобы не думать об этом почти)

4)если сети хватает - лечить приложение.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 21:50
    #39679910
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Спасибо, буду копать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 22:05
    #39679911
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Maxim BogukДальше в psql делать
1)explain (analyze, costs, buffers, timing) запроса общего

C таким explain получилось уже 52с.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 22:46
    #39679931
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
MegabyteMaxim BogukДальше в psql делать
1)explain (analyze, costs, buffers, timing) запроса общего

C таким explain получилось уже 52с.
Со 2,3го раза уже 18,20с. Но сам запрос все равно в районе 70с.
Что-то я не улавливаю причины...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 00:18
    #39679945
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Megabyte,

Вы абсолютно не туда смотрите.
Время исполнения запроса базой гораздо меньше и явно видно в выводе `EXPLAIN`.

То, что вы замеряете — пропускная способность сети + поведенческие особенности вашего клиентского приложения.
С этим помочь в рамках форума не выйдет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 10:42
    #39680043
Павел Лузанов
Павел Лузанов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Maxim Boguk2)\timing on
\o somefile
запрос;
чтобы посмотреть на сколько времени запрос выполняется в реальности и главное какой обьем данных он отдает

3)если с временем на приложении сильно не совпадает - смотреть на то какая вообще скорость сети и за какое время этот БОЛЬШОЙ ответ через нее пролезает (вряд ли у вас 10GBit кругом чтобы не думать об этом почти)

Недавно наткнулся, вроде в тему.
psql может много времени тратить на форматирование результата. Возможно и pgAdmin грешит этим, не проверял.

 
Несложные замеры в psql показывают, что выгрузка данных в файл командой SELECT выполняется существенно дольше, чем командой COPY .. TO.

В таблице tickets демонстрационной базы данных около 3 миллионов строк.
Попробуем выгрузить данные столбца contact_data в файл.
Сначала командой SELECT, а затем командой COPY .. TO.

Интересует время выгрузки, поэтому включим \timing.
Дополнительно замерим время между двумя вызовами функции clock_timestamp: до и после выгрузки.

Скрипт timing.sql:
--
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
\echo Run SELECT
select clock_timestamp() as d\gset
\timing on
\o contacts.txt
select contact_data from tickets;
\o
\timing off
select clock_timestamp() - :'d'::timestamptz as real_time;

\echo Run COPY .. TO
select clock_timestamp() as d\gset
\timing on
\o copy_contacts.txt
\copy (select contact_data from tickets) to stdout;
\o
\timing off
select clock_timestamp() - :'d'::timestamptz as real_time;


--

Запускаем:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
demo=# \i timing.sql
Run SELECT
Timing is on.
Time: 2125,645 ms (00:02,126)
Timing is off.
    real_time
-----------------
 00:00:09.856476
(1 row)

Run COPY .. TO
Timing is on.
Time: 2416,298 ms (00:02,416)
Timing is off.
    real_time
-----------------
 00:00:02.634909
(1 row)



Обращает на себя внимание.
1. Реальное время выполнения, полученное разницей вызовов clock_timestamp первой выгрузки (~10 сек), значительно больше чем показал \timing (~2 сек). Т.е. к показаниям \timing нужно относиться аккуратно.
2. Вторая выгрузка (COPY .. TO) заняла ~2,6 сек, что почти в 4 раза быстрее чем первая выгрузка.

Однако причина вовсе не в особенностях выполнения команд SELECT и COPY .. TO.
Столь существенная разница объясняется тем, что psql по умолчанию форматирует результаты запросов. В частности выравнивает ширину столбцов. Стоит только отключить выравнивание, как время обоих запросов становится похожим:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
demo=# \pset format unaligned
Output format is unaligned.
demo=# \i timing.sql
Run SELECT
Timing is on.
Time: 2156,758 ms (00:02,157)
Timing is off.
real_time
00:00:02.817774
(1 row)
Run COPY .. TO
Timing is on.
Time: 2422,347 ms (00:02,422)
Timing is off.
real_time
00:00:02.602836
(1 row)

...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 15:29
    #39680251
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
vyegorovТо, что вы замеряете — пропускная способность сети + поведенческие особенности вашего клиентского приложения.

Но MS SQL этому не подвержен. Не выгрузку оттуда сеть и приложение не влияет почему-то.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 16:15
    #39680292
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
MegabytevyegorovТо, что вы замеряете — пропускная способность сети + поведенческие особенности вашего клиентского приложения.

Но MS SQL этому не подвержен. Не выгрузку оттуда сеть и приложение не влияет почему-то.

Это уже вам тут не помогут. С таким вопросом.
Разбирайтесь сами. Непрофильный вопрос.
Профилируйте/смотрите что где тормозит и тд.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 16:29
    #39680311
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Maxim BogukMegabyteпропущено...

Но MS SQL этому не подвержен. Не выгрузку оттуда сеть и приложение не влияет почему-то.

Это уже вам тут не помогут. С таким вопросом.
Разбирайтесь сами. Непрофильный вопрос.
Профилируйте/смотрите что где тормозит и тд.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
Да это не вопрос был. Скорее рассуждение на тему влияния сети и приложения на длительность запроса...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 16:47
    #39680326
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
MegabyteДа это не вопрос был. Скорее рассуждение на тему влияния сети и приложения на длительность запроса...

Так протоколы то разные.
Кстати о протоколах у вас там в ответе двоичных данных (LO/bytea) нет случайно больших?
Попробуйте изменить bytea_output на hex если еще не (если у вас есть в ответе bytea большие).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 21:31
    #39680419
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Maxim BogukMegabyteДа это не вопрос был. Скорее рассуждение на тему влияния сети и приложения на длительность запроса...

Так протоколы то разные.
Кстати о протоколах у вас там в ответе двоичных данных (LO/bytea) нет случайно больших?
Попробуйте изменить bytea_output на hex если еще не (если у вас есть в ответе bytea большие).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
Посмотрю, спасибо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
02.08.2018, 22:18
    #39682842
Megabyte
Megabyte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Постгре начинает тормозить на запросе при пороговом значении limit
Коллеги, подскажите, а в Explain в:
Код: sql
1.
Buffers: shared hit=8357288 read=6165444 dirtied=44820 written=5590


Что означают последние 2 блока: dirtied, written? Что обозначают hit, read, я в курсе.
Поиском что-то не нашел ничего путного...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Постгре начинает тормозить на запросе при пороговом значении limit / 25 сообщений из 31, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 170ms
Закрыть
start [/forum/topic.php?fid=53&tablet=1&tid=1995641]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 46ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 60ms
get tp. blocked users:
 2ms
others: 16ms
total:  170ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]