ReSQL.ru
     
powered by simpleCommunicator - 2.0.54     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Тяжелый запрос к связанным таблицам
25 сообщений из 142, страница 1 из 6
  1  все
Тяжелый запрос к связанным таблицам
    #39327151
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
Есть 2 таблицы(material, materialdata)):

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CREATE TABLE san_materialdata (
    id integer NOT NULL,
    material_id integer NOT NULL,
    tag_id integer NOT NULL,

);

CREATE INDEX san_materialdata_76f094bc ON san_materialdata USING btree (tag_id);
CREATE INDEX san_materialdata_eb4b9aaa ON san_materialdata USING btree (material_id);

-------------------------------------------------

CREATE TABLE san_material (
    id integer NOT NULL,

    detection_datetime timestamp with time zone
);

CREATE INDEX san_material_detection_datetime_cb0a0120_uniq ON san_material USING btree (detection_datetime);




Выполняю такой запрос:
Код: sql
1.
2.
3.
4.
SELECT id FROM "san_material" WHERE ("san_material"."detection_datetime" BETWEEN '2016-10-10 00:00:00+03:00' AND '2016-10-14 23:59:59.999999+03:00' 
AND "san_material"."id" IN (SELECT U0."material_id" FROM "san_materialdata" U0 WHERE (U0."tag_id" IN (602)))) 
ORDER BY "san_material"."detection_datetime" DESC
limit 50



По идее должен выполниться быстро, так как на tag_id и detection_datetime висят индексы. Но в реальности происходит следующее:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
"Limit  (cost=632168.84..632168.96 rows=50 width=12) (actual time=15984.467..15984.485 rows=50 loops=1)"
"  ->  Sort  (cost=632168.84..632179.99 rows=4461 width=12) (actual time=15984.464..15984.474 rows=50 loops=1)"
"        Sort Key: san_material.detection_datetime DESC"
"        Sort Method: top-N heapsort  Memory: 27kB"
"        ->  Nested Loop  (cost=630741.35..632020.65 rows=4461 width=12) (actual time=8033.408..15966.010 rows=22716 loops=1)"
"              ->  HashAggregate  (cost=630740.92..630742.43 rows=151 width=4) (actual time=8033.052..8282.750 rows=314878 loops=1)"
"                    Group Key: u0.material_id"
"                    ->  Bitmap Heap Scan on san_materialdata u0  (cost=4652.60..630118.97 rows=248779 width=4) (actual time=245.386..7599.882 rows=516671 loops=1)"
"                          Recheck Cond: (tag_id = 602)"
"                          Rows Removed by Index Recheck: 19702747"
"                          Heap Blocks: exact=23189 lossy=240927"
"                          ->  Bitmap Index Scan on san_materialdata_76f094bc  (cost=0.00..4590.41 rows=248779 width=0) (actual time=235.536..235.536 rows=531585 loops=1)"
"                                Index Cond: (tag_id = 602)"
"              ->  Index Scan using san_material_pkey on san_material  (cost=0.43..8.46 rows=1 width=12) (actual time=0.024..0.024 rows=0 loops=314878)"
"                    Index Cond: (id = u0.material_id)"
"                    Filter: ((detection_datetime >= '2016-10-10 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-10-14 23:59:59.999999+03'::timestamp with time zone))"
"                    Rows Removed by Filter: 1"
"Planning time: 0.960 ms"
"Execution time: 15986.226 ms"



16 секунд длится запрос. Меня смущает Bitmap Heap Scan on san_materialdata u0 (cost=4652.60..630118.97 rows=248779 width=4). Это нормально?
Можно ли как нибудь оптимизировать? 16 секунд это еще не самый долгий запрос. Есть похожие запросы по несколько минут.
...
Рейтинг: 0 / 0
14.10.2016, 15:03
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327202
SharuPoNemnogu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SharuPoNemnogu
Участник
а чего не join?
...
Рейтинг: 0 / 0
14.10.2016, 15:50
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327206
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
SharuPoNemnoguа чего не join?
джойны чуть побыстрее работают, но не всегда:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
"Limit  (cost=1011190.20..1011190.33 rows=50 width=12) (actual time=12039.094..12039.107 rows=50 loops=1)"
"  ->  Sort  (cost=1011190.20..1011229.74 rows=15813 width=12) (actual time=12039.090..12039.096 rows=50 loops=1)"
"        Sort Key: san_material.detection_datetime DESC"
"        Sort Method: top-N heapsort  Memory: 27kB"
"        ->  Hash Join  (cost=379879.93..1010664.91 rows=15813 width=12) (actual time=11380.787..12031.376 rows=31987 loops=1)"
"              Hash Cond: (san_materialdata.material_id = san_material.id)"
"              ->  Bitmap Heap Scan on san_materialdata  (cost=4653.45..630392.97 rows=248888 width=4) (actual time=242.964..7264.115 rows=516936 loops=1)"
"                    Recheck Cond: (tag_id = 602)"
"                    Rows Removed by Index Recheck: 19702370"
"                    Heap Blocks: exact=23317 lossy=240925"
"                    ->  Bitmap Index Scan on san_materialdata_76f094bc  (cost=0.00..4591.23 rows=248888 width=0) (actual time=233.170..233.170 rows=531850 loops=1)"
"                          Index Cond: (tag_id = 602)"
"              ->  Hash  (cost=368078.14..368078.14 rows=411227 width=12) (actual time=4355.421..4355.421 rows=420070 loops=1)"
"                    Buckets: 131072  Batches: 8  Memory Usage: 3496kB"
"                    ->  Index Scan Backward using san_material_detection_datetime_cb0a0120_uniq on san_material  (cost=0.43..368078.14 rows=411227 width=12) (actual time=0.066..4043.210 rows=420070 loops=1)"
"                          Index Cond: ((detection_datetime >= '2016-10-10 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-10-14 00:00:00+03'::timestamp with time zone))"
"Planning time: 0.960 ms"
"Execution time: 12039.197 ms"
...
Рейтинг: 0 / 0
14.10.2016, 15:54
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327233
SharuPoNemnogu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SharuPoNemnogu
Участник
maxxstorm,

это вот с такого запроса explain ?
Код: plsql
1.
2.
3.
4.
5.
6.
7.
SELECT sm.id
FROM san_material sm
INNER JOIN san_materialdata smd ON sm.id = smd.material_id
           AND smd.tag_id = 602
WHERE sm.detection_datetime BETWEEN '2016-10-10 00:00:00+03:00' AND '2016-10-14 23:59:59.999999+03:00'
ORDER BY sm.detection_datetime DESC
LIMIT 50;
...
Рейтинг: 0 / 0
14.10.2016, 16:15
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327236
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
SharuPoNemnogumaxxstorm,

это вот с такого запроса explain ?
Код: plsql
1.
2.
3.
4.
5.
6.
7.
SELECT sm.id
FROM san_material sm
INNER JOIN san_materialdata smd ON sm.id = smd.material_id
           AND smd.tag_id = 602
WHERE sm.detection_datetime BETWEEN '2016-10-10 00:00:00+03:00' AND '2016-10-14 23:59:59.999999+03:00'
ORDER BY sm.detection_datetime DESC
LIMIT 50;


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
"Limit  (cost=1042286.46..1042286.59 rows=50 width=12) (actual time=12629.650..12629.662 rows=50 loops=1)"
"  ->  Sort  (cost=1042286.46..1042329.44 rows=17190 width=12) (actual time=12629.648..12629.652 rows=50 loops=1)"
"        Sort Key: sm.detection_datetime DESC"
"        Sort Method: top-N heapsort  Memory: 27kB"
"        ->  Hash Join  (cost=410493.83..1041715.42 rows=17190 width=12) (actual time=11955.837..12619.864 rows=35951 loops=1)"
"              Hash Cond: (smd.material_id = sm.id)"
"              ->  Bitmap Heap Scan on san_materialdata smd  (cost=4658.21..630645.20 rows=248986 width=4) (actual time=226.175..7282.886 rows=517132 loops=1)"
"                    Recheck Cond: (tag_id = 602)"
"                    Rows Removed by Index Recheck: 19701960"
"                    Heap Blocks: exact=23423 lossy=240924"
"                    ->  Bitmap Index Scan on san_materialdata_76f094bc  (cost=0.00..4595.96 rows=248986 width=0) (actual time=218.932..218.932 rows=532046 loops=1)"
"                          Index Cond: (tag_id = 602)"
"              ->  Hash  (cost=398064.20..398064.20 rows=447074 width=12) (actual time=4913.849..4913.849 rows=470948 loops=1)"
"                    Buckets: 131072  Batches: 8  Memory Usage: 3794kB"
"                    ->  Index Scan Backward using san_material_detection_datetime_cb0a0120_uniq on san_material sm  (cost=0.43..398064.20 rows=447074 width=12) (actual time=0.038..4578.718 rows=470948 loops=1)"
"                          Index Cond: ((detection_datetime >= '2016-10-10 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-10-14 23:59:59.999999+03'::timestamp with time zone))"
"Planning time: 0.751 ms"
"Execution time: 12629.752 ms"
...
Рейтинг: 0 / 0
14.10.2016, 16:16
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327239
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
К тому же, если джойн делать, то надо distinct или group by, потому что material_id в materialdata могут повторяться. Поэтому эксплейн еще вырастет
...
Рейтинг: 0 / 0
14.10.2016, 16:20
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327253
SharuPoNemnogu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SharuPoNemnogu
Участник
а если составной индекс на material_id, tag_id?
и еще попробовать вариант с exists, вместо join
...
Рейтинг: 0 / 0
14.10.2016, 16:27
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327260
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
автор(cost=0.00..4591.23 rows=248888 width=0) (actual time=233.170..233.170 rows=531850 loops=1)
похоже статистика устарела. Сделайте analyze san_materialdata.
...
Рейтинг: 0 / 0
14.10.2016, 16:36
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327304
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
1.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SELECT sm.id
FROM san_material sm
INNER JOIN san_materialdata smd ON sm.id = smd.material_id
           AND smd.tag_id = 602
WHERE 
           -- sm.detection_datetime BETWEEN '2016-10-10 00:00:00+03:00' AND '2016-10-14 23:59:59.999999+03:00' -- убивать
           sm.detection_datetime >='2016-10-10 00:00:00+03:00'
           AND sm.detection_datetime<'2016-10-15 00:00:00+03:00'
ORDER BY sm.detection_datetime DESC
LIMIT 50;



2 куда--то вот сюдой можно подумать


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SELECT sm.id
FROM san_materialdata smd
,LATERAL (SELECT  sm.id , sm.detection_datetime
    FROM san_material sm
    WHERE sm.id = smd.material_id
           AND sm.detection_datetime >='2016-10-10 00:00:00+03:00'
           AND sm.detection_datetime<'2016-10-15 00:00:00+03:00'
ORDER BY sm.detection_datetime DESC
LIMIT 50
) sm
WHERE 
           smd.tag_id = 602           
ORDER BY sm.detection_datetime DESC
LIMIT 50;



к чему индекс типа (id,detection_datetime) на san_material.
но, думается, т.к. таких тагов не менее 500 000 -- это будет плохо. (0.5 -- 2.5 ляма произвольных доступов)

тот случай, когда можно посмотреть возможность tag_ids integer[] в самой san_material (если оно редко обновляется). с гистами бтри_гистами и т.п.
...
Рейтинг: 0 / 0
14.10.2016, 17:47
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327306
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
qwwq,

чото я не падумал, что ид==пк, поторопился.
таки сколько записей в san_material" (без филтрации тагов) в оценке
Код: sql
1.
san_material" WHERE ("san_material"."detection_datetime" BETWEEN '2016-10-10 00:00:00+03:00' AND '2016-10-14 23:59:59.999999+03:00' )


?
...
Рейтинг: 0 / 0
14.10.2016, 17:54
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327309
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
qwwqqwwq,

чото я не падумал, что ид==пк, поторопился.
таки сколько записей в san_material" (без филтрации тагов) в оценке
Код: sql
1.
san_material" WHERE ("san_material"."detection_datetime" BETWEEN '2016-10-10 00:00:00+03:00' AND '2016-10-14 23:59:59.999999+03:00' )


?

6.000.000 в таблице san_material всего
110.000.000 в таблице san_materialdata всего

За эту конкретную дату примерно
500.000 в san_material
10.000.000 в san_materaildata
...
Рейтинг: 0 / 0
14.10.2016, 17:59
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327313
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
maxxstorm
6.000.000 в таблице san_material всего
110.000.000 в таблице san_materialdata всего

За эту конкретную дату примерно
500.000 в san_material
10.000.000 в san_materaildataт.е в среднем 20 тагов на материал ?
а сколько всего уникальных тагов ?
т.е. какая вероятность того, что первый попавшийся материал имеет заданный таг ?

м.б. просто бежать вдоль времени, и проверять (лейтералом и т.п.), что таг подходит ?
...
Рейтинг: 0 / 0
14.10.2016, 18:09
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327323
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
qwwq,

100 тагов. То есть вероятность 1 к 5, если предположить, что они равномерно повешены.

По поводу проверять лейтералом можно поподробнее?
...
Рейтинг: 0 / 0
14.10.2016, 18:24
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327339
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
maxxstorm,

`work_mem` покажите. И заодно попробуйте его поднять перед запуском запроса:
Код: sql
1.
SET work_mem TO '64MB';
...
Рейтинг: 0 / 0
14.10.2016, 19:00
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327433
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT  sm.id , sm.detection_datetime
FROM san_material sm
WHERE 
           sm.detection_datetime >='2016-10-10 00:00:00+03:00'
           AND sm.detection_datetime<'2016-10-15 00:00:00+03:00'
          AND EXISTS( SELECT 1 FROM 
                               FROM san_materialdata smd
                               WHERE 
                                    sm.id = smd.material_id
                                    AND smd.tag_id = 602
                                )
ORDER BY sm.detection_datetime DESC
LIMIT 50;


ожидаемые затраты - 50*5 произвольных доступов вдоль индекса + до ~20 [тагов в материале] -- вдоль проверяемого (полу--пессимистическая 50*5*20). если конечно вы оффсет потом не напишете.

неплохо пойдет индекс (tag_id,material_id) или симметричный. чтобы вот в ту 20--ку не упираться.
а лейтерал не нужен, вы из второй только фильтр дёргаете, его екзистс исполняет.
...
Рейтинг: 0 / 0
14.10.2016, 22:55
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327435
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
qwwq
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT  sm.id , sm.detection_datetime
FROM san_material sm
WHERE 
           sm.detection_datetime >='2016-10-10 00:00:00+03:00'
           AND sm.detection_datetime<'2016-10-15 00:00:00+03:00'
          AND EXISTS( SELECT 1  
                               FROM san_materialdata smd
                               WHERE 
                                    sm.id = smd.material_id
                                    AND smd.tag_id = 602
                                )
ORDER BY sm.detection_datetime DESC
LIMIT 50;


ожидаемые затраты - 50*5 произвольных доступов вдоль индекса + до ~20 [тагов в материале] -- вдоль проверяемого (полу--пессимистическая 50*5*20). если конечно вы оффсет потом не напишете.

неплохо пойдет индекс (tag_id,material_id) или симметричный. чтобы вот в ту 20--ку не упираться.
а лейтерал не нужен, вы из второй только фильтр дёргаете, его екзистс исполняет.
--поправил
...
Рейтинг: 0 / 0
14.10.2016, 22:57
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327951
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
vyegorovmaxxstorm,

`work_mem` покажите. И заодно попробуйте его поднять перед запуском запроса:
Код: sql
1.
SET work_mem TO '64MB';



4mb
...
Рейтинг: 0 / 0
17.10.2016, 08:48
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327953
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
qwwqqwwq
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT  sm.id , sm.detection_datetime
FROM san_material sm
WHERE 
           sm.detection_datetime >='2016-10-10 00:00:00+03:00'
           AND sm.detection_datetime<'2016-10-15 00:00:00+03:00'
          AND EXISTS( SELECT 1  
                               FROM san_materialdata smd
                               WHERE 
                                    sm.id = smd.material_id
                                    AND smd.tag_id = 602
                                )
ORDER BY sm.detection_datetime DESC
LIMIT 50;


ожидаемые затраты - 50*5 произвольных доступов вдоль индекса + до ~20 [тагов в материале] -- вдоль проверяемого (полу--пессимистическая 50*5*20). если конечно вы оффсет потом не напишете.

неплохо пойдет индекс (tag_id,material_id) или симметричный. чтобы вот в ту 20--ку не упираться.
а лейтерал не нужен, вы из второй только фильтр дёргаете, его екзистс исполняет.
--поправил

Те же 16 секунд. Причем первоначально запрос выполнялся 150 секунд, а повторно 16. И мои оригинальные столько же. Походу 16 секунд это кэш, а 150 реальное время выполнения
...
Рейтинг: 0 / 0
17.10.2016, 08:52
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327954
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
"Limit  (cost=639430.56..639430.68 rows=50 width=12) (actual time=92772.916..92772.935 rows=50 loops=1)"
"  ->  Sort  (cost=639430.56..639440.74 rows=4075 width=12) (actual time=92772.915..92772.922 rows=50 loops=1)"
"        Sort Key: sm.detection_datetime DESC"
"        Sort Method: top-N heapsort  Memory: 27kB"
"        ->  Nested Loop  (cost=638015.89..639295.19 rows=4075 width=12) (actual time=48860.399..92755.021 rows=15613 loops=1)"
"              ->  HashAggregate  (cost=638015.46..638016.97 rows=151 width=4) (actual time=48860.197..49033.202 rows=193278 loops=1)"
"                    Group Key: smd.material_id"
"                    ->  Bitmap Heap Scan on san_materialdata smd  (cost=4706.84..637386.34 rows=251648 width=4) (actual time=225.466..48465.411 rows=313019 loops=1)"
"                          Recheck Cond: (tag_id = 622)"
"                          Heap Blocks: exact=173042"
"                          ->  Bitmap Index Scan on san_materialdata_76f094bc  (cost=0.00..4643.93 rows=251648 width=0) (actual time=126.899..126.899 rows=313158 loops=1)"
"                                Index Cond: (tag_id = 622)"
"              ->  Index Scan using san_material_pkey on san_material sm  (cost=0.43..8.46 rows=1 width=12) (actual time=0.225..0.225 rows=0 loops=193278)"
"                    Index Cond: (id = smd.material_id)"
"                    Filter: ((detection_datetime >= '2016-10-10 00:00:00+03'::timestamp with time zone) AND (detection_datetime < '2016-10-15 00:00:00+03'::timestamp with time zone))"
"                    Rows Removed by Filter: 1"
"Planning time: 0.943 ms"
"Execution time: 92773.037 ms"
...
Рейтинг: 0 / 0
17.10.2016, 08:53
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327964
Фотография Legushka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Legushka
Участник
maxxstorm, попробуйте сделать индекс для таблицы san_material на поле detection_datetime
...
Рейтинг: 0 / 0
17.10.2016, 09:17
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39327965
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
Legushkamaxxstorm, попробуйте сделать индекс для таблицы san_material на поле detection_datetime

Индекс имеется
...
Рейтинг: 0 / 0
17.10.2016, 09:18
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39328007
Фотография Legushka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Legushka
Участник
maxxstormИндекс имеется
могли бы вы показать как создан индекс на detection_datetime?

может попробовать делать не AND sm.detection_datetime<'2016-10-15 00:00:00+03:00'
a по включительную дату:
AND sm.detection_datetime<='2016-10-14 23:59:59+03:00'

просто в плане не видно что бы индекс работал.
...
Рейтинг: 0 / 0
17.10.2016, 10:15
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39328009
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
LegushkamaxxstormИндекс имеется
могли бы вы показать как создан индекс на detection_datetime?

может попробовать делать не AND sm.detection_datetime<'2016-10-15 00:00:00+03:00'
a по включительную дату:
AND sm.detection_datetime<='2016-10-14 23:59:59+03:00'

просто в плане не видно что бы индекс работал.

А вот в первом посте я написал:

Код: sql
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE san_material (
    id integer NOT NULL,

    detection_datetime timestamp with time zone
);

CREATE INDEX san_material_detection_datetime_cb0a0120_uniq ON san_material USING btree (detection_datetime);
...
Рейтинг: 0 / 0
17.10.2016, 10:16
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39328018
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
LegushkamaxxstormИндекс имеется
могли бы вы показать как создан индекс на detection_datetime?

может попробовать делать не AND sm.detection_datetime<'2016-10-15 00:00:00+03:00'
a по включительную дату:
AND sm.detection_datetime<='2016-10-14 23:59:59+03:00'

просто в плане не видно что бы индекс работал.

Так и не должен работать учитывая
авторЗа эту конкретную дату примерно
500.000 в san_material
полмиллиона строк под условие.
Вопрос к автору... как вы ожидаете при то что у вас 500.000 строк на дату "По идее должен выполниться быстро"?


Я бы сделал индекс вида san_material(id, detection_datetime) для начала.
И очень сильно бы поднял work_mem (до 32 или 64MB пока у вас не станет lossy=0 вместо lossy=240927 в плане).

Скорее всего станет лучше. Ну и увеличить shared_buffers чтобы данные нормально в памяти помещались.

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
17.10.2016, 10:22
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39328060
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
maxxstorm,

В первом плане было:
Код: sql
1.
2.
3.
4.
"                    ->  Bitmap Heap Scan on san_materialdata u0  (cost=4652.60..630118.97 rows=248779 width=4) (actual time=245.386..7599.882 rows=516671 loops=1)"
"                          Recheck Cond: (tag_id = 602)"
"                          Rows Removed by Index Recheck: 19702747"
"                          Heap Blocks: exact=23189 lossy=240927"


Потом стало:
Код: sql
1.
2.
3.
"                    ->  Bitmap Heap Scan on san_materialdata smd  (cost=4706.84..637386.34 rows=251648 width=4) (actual time=225.466..48465.411 rows=313019 loops=1)"
"                          Recheck Cond: (tag_id = 622)"
"                          Heap Blocks: exact=173042"


Что за сервер? И что на нём кроме базы бегает?
...
Рейтинг: 0 / 0
17.10.2016, 11:30
| Ответить | Цитировать | Написать  
25 сообщений из 142, страница 1 из 6
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Тяжелый запрос к связанным таблицам
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=39327253&tid=1996781]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 68ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 68ms
get tp. blocked users:
 1ms
others: 16ms
total:  196ms
созд. / загр.: 196ms
x
x
Закрыть


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