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

База читает не по-строчно, а по-блочно.
Было `read=275479` произвольных обращений к диску. Чтобы точно знать время IO операций, можно включить `track_io_timing=on`, тогда в плане будет видно реальное время работы с дисками.

`dirtied` значит, что ваш запрос должен был "подчищать" за другими запросами, проставля hint bits в записях.

Вот второй раз делаю этот же запрос:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
"Aggregate  (cost=26045.35..26045.36 rows=1 width=0) (actual time=96550.311..96550.312 rows=1 loops=1)"
"  Buffers: shared hit=20760 read=72523 dirtied=98"
"  ->  Index Only Scan using san_material_detection_datetime_cb0a0120_uniq on san_material  (cost=0.43..26000.29 rows=18024 width=0) (actual time=28.380..96475.752 rows=90156 loops=1)"
"        Index Cond: ((detection_datetime >= '2016-12-04 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-12-04 23:59:59.999999+03'::timestamp with time zone))"
"        Heap Fetches: 91691"
"        Buffers: shared hit=20760 read=72523 dirtied=98"
"Planning time: 0.172 ms"
"Execution time: 96550.346 ms"



Откуда щас dirtied взялись? Это данные за вчера и апдейтов по ним не бывает.
...
Рейтинг: 0 / 0
05.12.2016, 10:36
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39360287
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
qwwqmaxxstormНе поверю, что чтобы прочитать 90000 строк из индекса, понадобится 365 секунд:


если базе придется читать 90000 строк из маленькой таблички на 90 000--900 000 строк, то она просто забьёт на индексы и прочитает табличку последовательным доступом. т.е. относительно быстро. и отфильтрует.


если же ей придется читать 90000 "по индексу" (из большой реально таблички, которую последовательно читать дорого) -- то это будет уже произвольный доступ. и , в случае механики, "чюдес не бываит" -- вряд ли блоки окажутся расположены так удачно, что затраты на полоборота диска куда--то все пропадут. только если только что что--то типа "кластер" было вдоль этого индекса сказано. и выборка подряд вдоль кластерного индекса.

ну и если записей на блок много приходится и коэффициент перекрытия случится удачный (т.е. придется читать физически много меньше 90000 блоков)-- случится экономия в числе доступов (позиционировании головы).


к тому же "по индексу", но "с доступом к самим записям" -- это несколько дороже, чем "только по индексу" -- там как бе 2 отдельные физические реляции получаются. и к обеим -- физически доступаться.



зы. скоро обещают x--память, или как её -- скоро про механический доступ можно будет не вспоминать

Делаю тот же запрос на тестовом сервере:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
"Aggregate  (cost=5054.53..5054.54 rows=1 width=0) (actual time=2771.180..2771.180 rows=1 loops=1)"
"  Buffers: shared hit=116282 read=573 dirtied=1688"
"  ->  Index Only Scan using san_material_detection_datetime_cb0a0120_uniq on san_material  (cost=0.43..5040.38 rows=5662 width=0) (actual time=40.119..2763.133 rows=56252 loops=1)"
"        Index Cond: ((detection_datetime >= '2016-12-04 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-12-04 23:59:59.999999+03'::timestamp with time zone))"
"        Heap Fetches: 108783"
"        Buffers: shared hit=116282 read=573 dirtied=1688"
"Planning time: 0.425 ms"
"Execution time: 2771.216 ms"



Разница в скорости на 2 порядка. Разница в количестве записей 1:1.5, к тому же на тестовом сервере диски старые и медленные.
...
Рейтинг: 0 / 0
05.12.2016, 10:53
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39360319
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
maxxstorm
Вот второй раз делаю этот же запрос:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
"Aggregate  (cost=26045.35..26045.36 rows=1 width=0) (actual time=96550.311..96550.312 rows=1 loops=1)"
"  Buffers: shared hit=20760 read=72523 dirtied=98"
"  ->  Index Only Scan using san_material_detection_datetime_cb0a0120_uniq on san_material  (cost=0.43..26000.29 rows=18024 width=0) (actual time=28.380..96475.752 rows=90156 loops=1)"
"        Index Cond: ((detection_datetime >= '2016-12-04 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-12-04 23:59:59.999999+03'::timestamp with time zone))"
"        Heap Fetches: 91691"
"        Buffers: shared hit=20760 read=72523 dirtied=98"
"Planning time: 0.172 ms"
"Execution time: 96550.346 ms"





maxxstorm<>
Делаю тот же запрос на тестовом сервере:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
"Aggregate  (cost=5054.53..5054.54 rows=1 width=0) (actual time=2771.180..2771.180 rows=1 loops=1)"
"  Buffers: shared hit=116282 read=573 dirtied=1688"
"  ->  Index Only Scan using san_material_detection_datetime_cb0a0120_uniq on san_material  (cost=0.43..5040.38 rows=5662 width=0) (actual time=40.119..2763.133 rows=56252 loops=1)"
"        Index Cond: ((detection_datetime >= '2016-12-04 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-12-04 23:59:59.999999+03'::timestamp with time zone))"
"        Heap Fetches: 108783"
"        Buffers: shared hit=116282 read=573 dirtied=1688"
"Planning time: 0.425 ms"
"Execution time: 2771.216 ms"



Разница в скорости на 2 порядка. Разница в количестве записей 1:1.5, к тому же на тестовом сервере диски старые и медленные.

читать ещё не научили ?
...
Рейтинг: 0 / 0
05.12.2016, 11:13
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39360470
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
qwwqmaxxstormВот второй раз делаю этот же запрос:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
"Aggregate  (cost=26045.35..26045.36 rows=1 width=0) (actual time=96550.311..96550.312 rows=1 loops=1)"
"  Buffers: shared hit=20760 read=72523 dirtied=98"
"  ->  Index Only Scan using san_material_detection_datetime_cb0a0120_uniq on san_material  (cost=0.43..26000.29 rows=18024 width=0) (actual time=28.380..96475.752 rows=90156 loops=1)"
"        Index Cond: ((detection_datetime >= '2016-12-04 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-12-04 23:59:59.999999+03'::timestamp with time zone))"
"        Heap Fetches: 91691"
"        Buffers: shared hit=20760 read=72523 dirtied=98"
"Planning time: 0.172 ms"
"Execution time: 96550.346 ms"





maxxstorm<>
Делаю тот же запрос на тестовом сервере:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
"Aggregate  (cost=5054.53..5054.54 rows=1 width=0) (actual time=2771.180..2771.180 rows=1 loops=1)"
"  Buffers: shared hit=116282 read=573 dirtied=1688"
"  ->  Index Only Scan using san_material_detection_datetime_cb0a0120_uniq on san_material  (cost=0.43..5040.38 rows=5662 width=0) (actual time=40.119..2763.133 rows=56252 loops=1)"
"        Index Cond: ((detection_datetime >= '2016-12-04 00:00:00+03'::timestamp with time zone) AND (detection_datetime <= '2016-12-04 23:59:59.999999+03'::timestamp with time zone))"
"        Heap Fetches: 108783"
"        Buffers: shared hit=116282 read=573 dirtied=1688"
"Planning time: 0.425 ms"
"Execution time: 2771.216 ms"



Разница в скорости на 2 порядка. Разница в количестве записей 1:1.5, к тому же на тестовом сервере диски старые и медленные.

читать ещё не научили ?

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

Ну... SSD оно всегда хорошо. Но у меня есть мысль, что у вас могут быть распухшие таблицы и/или индексы.
Там много UPDATE/DELETE операций?

Можно сделать идентичный существующему индекс с другим именем и сравнить размеры.
Можно таблицы "пожать", и индексы тогда точно надо будет перестроить.
...
Рейтинг: 0 / 0
05.12.2016, 15:33
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39360587
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
vyegorovmaxxstorm,

Ну... SSD оно всегда хорошо. Но у меня есть мысль, что у вас могут быть распухшие таблицы и/или индексы.
Там много UPDATE/DELETE операций?

Можно сделать идентичный существующему индекс с другим именем и сравнить размеры.
Можно таблицы "пожать", и индексы тогда точно надо будет перестроить.

2-3млн инсертов + 200к делетов в сутки
...
Рейтинг: 0 / 0
05.12.2016, 15:38
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39360593
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
maxxstorm,

А настройки autovcauum-а наверно умолчательные, да?
Код: sql
1.
SELECT name,setting FROM pg_settings WHERE name ~ 'vacuum';
...
Рейтинг: 0 / 0
05.12.2016, 15:41
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39360594
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
vyegorovmaxxstorm,

А настройки autovcauum-а наверно умолчательные, да?
Код: sql
1.
SELECT name,setting FROM pg_settings WHERE name ~ 'vacuum';



Настойки по умолчанию, но почему то автовакуум не отрабатывает. Мы запускаем вручную vacuum analyze.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
"autovacuum";"on"
"autovacuum_analyze_scale_factor";"0.1"
"autovacuum_analyze_threshold";"50"
"autovacuum_freeze_max_age";"200000000"
"autovacuum_max_workers";"3"
"autovacuum_multixact_freeze_max_age";"400000000"
"autovacuum_naptime";"60"
"autovacuum_vacuum_cost_delay";"20"
"autovacuum_vacuum_cost_limit";"-1"
"autovacuum_vacuum_scale_factor";"0.2"
"autovacuum_vacuum_threshold";"50"
"autovacuum_work_mem";"-1"
"log_autovacuum_min_duration";"-1"
"vacuum_cost_delay";"0"
"vacuum_cost_limit";"200"
"vacuum_cost_page_dirty";"20"
"vacuum_cost_page_hit";"1"
"vacuum_cost_page_miss";"10"
"vacuum_defer_cleanup_age";"0"
"vacuum_freeze_min_age";"50000000"
"vacuum_freeze_table_age";"150000000"
"vacuum_multixact_freeze_min_age";"5000000"
"vacuum_multixact_freeze_table_age";"150000000"
...
Рейтинг: 0 / 0
05.12.2016, 15:42
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39360597
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT name,setting FROM pg_settings WHERE name ~ 'vacuum';

select relname, last_vacuum, last_analyze,last_autovacuum,last_autoanalyze

from pg_stat_all_tables

where relname in ('san_materialdata', 'san_material');



Код: sql
1.
2.
"san_materialdata";"2016-12-02 12:57:49.200485+03";"2016-12-02 13:02:19.212248+03";"";"2016-11-16 19:02:07.448167+03"
"san_material";"2016-12-02 11:35:05.015388+03";"2016-12-02 11:51:44.486291+03";"2016-11-29 21:52:19.955824+03";"2016-12-05 15:29:49.978115+03"
...
Рейтинг: 0 / 0
05.12.2016, 15:45
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39360701
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
maxxstorm2-3млн инсертов + 200к делетов в сутки

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

но пока физ--смысл вашей кухни мне не настолько ясен, чтобы тут что--то советовать наверняка. -- партицирование всё сильно усложнит планировщику. а тем более -- sql--деву.
...
Рейтинг: 0 / 0
05.12.2016, 17:06
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376691
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
Сравниваю с аналогичным запросом из другой бд(размер 50гб):

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
explain
(analyze, buffers, verbose)
select count(id) from sources_article

"Aggregate  (cost=584214.84..584214.85 rows=1 width=4) (actual time=8779.156..8779.156 rows=1 loops=1)"
"  Output: count(id)"
"  Buffers: shared hit=18937 read=428234 dirtied=148 written=114"
"  ->  Seq Scan on public.sources_article  (cost=0.00..556806.07 rows=10963507 width=4) (actual time=0.036..7306.261 rows=10981230 loops=1)"
"        Output: id"
"        Buffers: shared hit=18937 read=428234 dirtied=148 written=114"
"Total runtime: 8779.237 ms"



9 секунд и 428234 обращенй к диску.
Делаю аналочичный запрос в свою таблицу(размер бд 150гб):

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
explain
(analyze, buffers, verbose)
select count(id) from san_material;

 Aggregate  (cost=1271243.88..1271243.89 rows=1 width=4) (actual time=192019.742..192019.743 rows=1 loops=1)
   Output: count(id)
   Buffers: shared hit=6809984 read=72450 dirtied=4851
   ->  Index Only Scan using san_material_pkey on public.san_material  (cost=0.56..1227437.79 rows=17522436 width=4) (actual time=0.123..189988.281 rows=15647414 loops=1)
         Output: id
         Heap Fetches: 322492
         Buffers: shared hit=6809984 read=72450 dirtied=4851
 Planning time: 0.115 ms
 Execution time: 192019.800 ms



Почему кост в 25 раз больше? Ведь количество записей одного порядка(11 и 15 млн соответственно)
...
Рейтинг: 0 / 0
28.12.2016, 11:41
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376725
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
maxxstorm,

1. покажите
Код: sql
1.
2.
3.
4.
5.
6.
select * from pg_settings 
where 
	name ilike '%cost%'
	and name NOT ilike'%vacuum%'
order by name	;


с обеих; сравните попунктно.

и по мелочи :
2. при расчете коста использовано 17 и 11 лямов -- по ожиданиям, а не по факту. (мелочь, а поправочка)
3. операции разные. (хотя и не настолько)
...
Рейтинг: 0 / 0
28.12.2016, 12:03
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376731
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
qwwqmaxxstorm,

1. покажите
Код: sql
1.
2.
3.
4.
5.
6.
select * from pg_settings 
where 
	name ilike '%cost%'
	and name NOT ilike'%vacuum%'
order by name	;


с обеих; сравните попунктно.

и по мелочи :
2. при расчете коста использовано 17 и 11 лямов -- по ожиданиям, а не по факту. (мелочь, а поправочка)
3. операции разные. (хотя и не настолько)

Абсолютно одинаковые дефолтные значения

Код: sql
1.
2.
3.
4.
5.
"cpu_index_tuple_cost";"0.005"
"cpu_operator_cost";"0.0025"
"cpu_tuple_cost";"0.01"
"random_page_cost";"4"
"seq_page_cost";"1"



Разные операция в смысле seq scan и index scan?
...
Рейтинг: 0 / 0
28.12.2016, 12:07
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376744
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
maxxstormРазные операция в смысле seq scan и index scan?а что, по буквам названия совпадают, чоль ?

хотя почему подавлено сравнение со сек--сканом для вас -- не понял. думаю у вас какие--то енейблы отключены (что дает разовую прибавку к косту в 10 ярдов)

посмотрите
Код: sql
1.
2.
3.
4.
5.
select * from pg_settings 
where 
	name ilike 'enable%'
order by name	;
...
Рейтинг: 0 / 0
28.12.2016, 12:19
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376750
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
maxxstorm,

Львиную долю в цене составляет обращение к буферам. Если размер базы в 3 раза больше, то это имеет значение.

Для маленькой базы у вас:
Код: sql
1.
2.
3.
  ->  Seq Scan on public.sources_article  (cost=0.00..556806.07 rows=10963507 width=4) (actual time=0.036..7306.261 rows=10981230 loops=1)
        Output: id
        Buffers: shared hit=18937 read=428234 dirtied=148 written=114


Для большой:
Код: sql
1.
2.
3.
4.
   ->  Index Only Scan using san_material_pkey on public.san_material  (cost=0.56..1227437.79 rows=17522436 width=4) (actual time=0.123..189988.281 rows=15647414 loops=1)
         Output: id
         Heap Fetches: 322492
         Buffers: shared hit=6809984 read=72450 dirtied=4851


Кол-во обращений надо считать общее, а не только `read`. И общее кол-во обращений во 2-м случае на порядок больше, ибо
это проход по индексу, произвольный доступ. Да ещё с переодическим "подглядыванием" в кучу.
...
Рейтинг: 0 / 0
28.12.2016, 12:22
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376767
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
vyegorov,

там 2 вопроса --
1. почему оно секвенс скан отбросило (который видимо задизейблен)

2. зачем для IOS БЕЗ УСЛОВИЙ (т.е. по всем листам == по всем блокам индекса) рендом доступ ? ожидают очень плохую карту ? (можно ожидания где--то увидеть?). или индекс принципиально всегда так фрагментирован, что обязательно поблочный рендом доступ ? //и никогда и никак -- не прочитать одним куском
...
Рейтинг: 0 / 0
28.12.2016, 12:33
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376785
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
qwwqпосмотрите
Код: sql
1.
2.
3.
4.
5.
select * from pg_settings 
where 
	name ilike 'enable%'
order by name	;



Все настройки одинаковые:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
"enable_bitmapscan";"on"
"enable_hashagg";"on"
"enable_hashjoin";"on"
"enable_indexonlyscan";"on"
"enable_indexscan";"on"
"enable_material";"on"
"enable_mergejoin";"on"
"enable_nestloop";"on"
"enable_seqscan";"on"
"enable_sort";"on"
"enable_tidscan";"on"
...
Рейтинг: 0 / 0
28.12.2016, 12:43
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376789
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
Сделал на своей БД

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
set enable_indexscan=off;
SET
analize=> set enable_indexonlyscan=off;
SET
analize=> explain
(analyze, buffers, verbose)
select count(id) from san_material;
                                                                 QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=4390342.45..4390342.46 rows=1 width=4) (actual time=593738.626..593738.627 rows=1 loops=1)
   Output: count(id)
   Buffers: shared hit=512144 read=3659168 dirtied=373
   ->  Seq Scan on public.san_material  (cost=0.00..4346536.36 rows=17522436 width=4) (actual time=0.046..591029.866 rows=15650113 loops=1)
         Output: id
         Buffers: shared hit=512144 read=3659168 dirtied=373
 Planning time: 0.171 ms
 Execution time: 593738.760 ms



4 миллиона обращений против 400к для первой
...
Рейтинг: 0 / 0
28.12.2016, 12:46
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376794
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
qwwq,

Вопросы интересные.

1. Тут надо у @maxxstorm спрость что происходит. Я бы пробовал включать-выключать разные `enabled_%` опции и сравнивать косты.
Ещё было бы интересно увидеть размер таблицы и индексов в блоках и записях (relpages и reltuples) из `pg_class`, а также кол-во удалённых записей в `pg_stat_user_tables`.

2. Тут я не уверен, надо код смотреть или же гуглить. Мне думается, что ПЖ не умеет делать IndexFastFullScan (в терминах О), он читает листья в порядке индекса, следуя по ссылкам в служебной зоне страниц -- это и приводит к произвольному доступу.
...
Рейтинг: 0 / 0
28.12.2016, 12:50
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376798
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
maxxstorm,

А много изменений в таблице? Может она у вас банально распухла?
...
Рейтинг: 0 / 0
28.12.2016, 12:52
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376801
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
vyegorovmaxxstorm,

А много изменений в таблице? Может она у вас банально распухла?

апдейты редко бывают, автоваккум включен вроде, отрабатывает каждый день.
Как определить, что распухла?
...
Рейтинг: 0 / 0
28.12.2016, 12:53
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376814
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
vyegorov,

там разница в буферах секскана -- тоже порядок. (при разнице ожиданий строк около 1,7)
видимо очень пустые блоки приходится читать в количествах.
...
Рейтинг: 0 / 0
28.12.2016, 13:00
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376824
maxxstorm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxxstorm
Участник
qwwqvyegorov,

там разница в буферах секскана -- тоже порядок. (при разнице ожиданий строк около 1,7)
видимо очень пустые блоки приходится читать в количествах.

vacuum full поможет?
...
Рейтинг: 0 / 0
28.12.2016, 13:11
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376825
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
maxxstorm,

Для начала, посмотрите на вывод запроса (в `psql`):
Код: sql
1.
select * from pg_stat_user_tables where relname='san_material'\x\g\x



Затем посмотреть на вывод такого запроса (осторожно, читает всю таблицу):
Код: sql
1.
2.
CREATE EXTENSION IF NOT EXISTS pgstattuple;
select * from pgstattuple('san_material'::regclass)\x\g\x
...
Рейтинг: 0 / 0
28.12.2016, 13:12
| Ответить | Цитировать | Написать  
Тяжелый запрос к связанным таблицам
    #39376828
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
maxxstormvacuum full поможет?
Надо выяснить для начала что там такое. Если распухла, то:
поможет

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


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