ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Оптимизация запроса
9 сообщений из 9, страница 1 из 1
Оптимизация запроса
    #39120871
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
Прошу пояснить почему так долго выполняется запрос
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
select distinct on (((data_json ->> 'singleNumber'::text))::bigint)
id
, (((data_json ->> 'singleNumber'::text))::bigint)
, (data_json #>>'{signByte2,following}')::integer
, data_json
, date_priema
, date_save_db
, id_morg
from oi.base_pasu_p1 
where date_save_db > 'today'
and (data_json #>>'{signByte2,following}')::integer in (0,1)
order by (((data_json ->> 'singleNumber'::text))::bigint), date_priema desc


План
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
QUERY PLAN
Unique  (cost=13772.41..13797.42 rows=200 width=60) (actual time=22805.334..23477.556 rows=4535 loops=1)
  Buffers: shared hit=32582, temp read=27933 written=27933
  ->  Sort  (cost=13772.41..13784.92 rows=5003 width=60) (actual time=22805.330..23398.213 rows=478357 loops=1)
        Sort Key: (((base_pasu_p1.data_json ->> 'singleNumber'::text))::bigint), base_pasu_p1.date_priema
        Sort Method: external merge  Disk: 223424kB
        Buffers: shared hit=32582, temp read=27933 written=27933
        ->  Result  (cost=0.00..13465.01 rows=5003 width=60) (actual time=104.710..19846.585 rows=478357 loops=1)
              Buffers: shared hit=32582
              ->  Append  (cost=0.00..13389.97 rows=5003 width=60) (actual time=104.651..547.460 rows=478357 loops=1)
                    Buffers: shared hit=32582
                    ->  Seq Scan on base_pasu_p1  (cost=0.00..0.00 rows=1 width=60) (actual time=0.001..0.001 rows=0 loops=1)
                          Filter: ((date_save_db > '2015-12-04 00:00:00+03'::timestamp with time zone) AND (((data_json #>> '{signByte2,following}'::text[]))::integer = ANY ('{0,1}'::integer[])))
                    ->  Bitmap Heap Scan on base_pasu_p1_2015_12_04  (cost=95.62..13389.97 rows=5002 width=60) (actual time=104.647..480.709 rows=478357 loops=1)
                          Recheck Cond: (((data_json #>> '{signByte2,following}'::text[]))::integer = ANY ('{0,1}'::integer[]))
                          Filter: (date_save_db > '2015-12-04 00:00:00+03'::timestamp with time zone)
                          Buffers: shared hit=32582
                          ->  Bitmap Index Scan on base_pasu_p1_2015_12_04_idx  (cost=0.00..94.37 rows=5003 width=0) (actual time=92.254..92.254 rows=478357 loops=1)
                                Index Cond: (((data_json #>> '{signByte2,following}'::text[]))::integer = ANY ('{0,1}'::integer[]))
                                Buffers: shared hit=1315
Total runtime: 25009.115 ms



Видно, что основное время расходуется в этой части операции
Код: sql
1.
2.
        ->  Result  (cost=0.00..13465.01 rows=5003 width=60) (actual time=104.710..19846.585 rows=478357 loops=1)
              Buffers: shared hit=32582


Что делает СУБД в этом месте?
Как снизить издержки?
Увеличение work_mem результата не дает, разве что сортировка в памяти происходит, но она и так относительно невелика.
Спасибо.
...
Рейтинг: 0 / 0
04.12.2015, 17:12
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #39120881
Lonepsycho
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lonepsycho
Участник
big-trot,

количество запланированных и реальных строк (rows) сильно различяются. непробовали ANALYZE base_pasu_p1_2015_12_04?
...
Рейтинг: 0 / 0
04.12.2015, 17:18
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #39120891
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
Lonepsycho непробовали ANALYZE base_pasu_p1_2015_12_04?
Сделал, не помогает. Количество стало совпадать.
...
Рейтинг: 0 / 0
04.12.2015, 17:25
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #39120901
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
После ANALYZE base_pasu_p1_2015_12_04 отвалилось сканирование по индексу и общее время запроса на 30%
...
Рейтинг: 0 / 0
04.12.2015, 17:31
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #39120902
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
увеличилось
...
Рейтинг: 0 / 0
04.12.2015, 17:32
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #39120932
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
Несколько изменил запрос, скорость увеличилась в три раза (~ 10 сек.).
Полагаю, что ничего нельзя сделать еще лучше, это из-за distinct on скорее всего.
Сканируется вся таблица, далее сортируется и отбрасываются дублеры, всё это очень долго на полмиллиона записей.
...
Рейтинг: 0 / 0
04.12.2015, 18:01
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #39120951
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
big-trotНесколько изменил запрос, скорость увеличилась в три раза (~ 10 сек.).
Полагаю, что ничего нельзя сделать еще лучше, это из-за distinct on скорее всего.
Сканируется вся таблица, далее сортируется и отбрасываются дублеры, всё это очень долго на полмиллиона записей.

как бы техника выборки для подавления distinct -ом известна.
основывается на подходящем индексе
у вас был бы что--то вроде составного по:

Код: sql
1.
2.
3.
4.
... using btree (
( (data_json #>>'{signByte2,following}')::integer 
, (((data_json ->> 'singleNumber'::text))::bigint), date_priema desc
)


далее -- как где--то богук приводил. (искать по автору и distinct)

http://www.sql.ru/forum/882778/bystryy-podschet-distinct-values-po-indeksirovannym-polyam?mid=11326416#11326416

но у вас же наверное и другие выборки того же типа , но по другим "полям" говноджейсона,
а это -- покрыть многообразие -- уже сложнее.
...
Рейтинг: 0 / 0
04.12.2015, 18:14
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #39121040
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
big-trotНесколько изменил запрос, скорость увеличилась в три раза (~ 10 сек.).
Полагаю, что ничего нельзя сделать еще лучше, это из-за distinct on скорее всего.
Сканируется вся таблица, далее сортируется и отбрасываются дублеры, всё это очень долго на полмиллиона записей.

Все время уходит на работу с JSON, доступ к его элементам (особенно если это JSON а не JSONB) - крайне дорогой так как каждый раз парсится весть текст JSOIN (т.е сколько раз там data_json парсится у вас на 1 строку вообще сложно сказать).
JSON не для тех полей в содержимое которых база будет часто лазить, для этого колонки есть в таблице.

Т.е. если у вас образовался частовызываемый запрос по элементу JSON - этот элемент должен стать колонкой в таблице.

PS: Не удивлен, я вполне ожидал что с появлением JSON начнут такое делать и жаловаться что медленно работает. Классический пример как делать нельзя с postgresql и json.

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
04.12.2015, 20:36
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #39121166
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Maxim Boguk,

распарсить 478357 строк после фильтра , но до "дистинкт он"
и распарсить rows=4535 вдоль seek по индексу -- 2 немного отдельные (по трудоёмкости) задачи.

/*там изрядная часть json--барахла может в тостах валяться -- при проходе Loose indexscan--ом изрядную часть этих ненужных доступов можно буит отсечь. (т.к. они не потребуются)*/


а с тем, что запихивание заведомо реляционной структуры в жейсона -- зло -- полностью согласен. многажды именно этому пассажыру говорено.
но разве ж убедишь.
...
Рейтинг: 0 / 0
05.12.2015, 00:44
| Ответить | Цитировать | Написать  
9 сообщений из 9, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Оптимизация запроса
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=39120871&tid=1997586]:
 0ms
get settings:
 10ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 167ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 66ms
get tp. blocked users:
 2ms
others: 210ms
total:  495ms
созд. / загр.: 495ms
x
x
Закрыть


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