ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Быстрый запрос в explain analyze но медленный по факту
25 сообщений из 65, страница 1 из 3
  1  все
Быстрый запрос в explain analyze но медленный по факту
    #38917216
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Добрый день. Не могу понять в чем дело, копаюсь уже неделю, наверное. Есть БД в которой сейчас примерно 260 таблиц, есть такие таблицы как статистика, они унаследованы от основной таблицы статистики, т.е. в базе реализовано партицирование по времени и id юзера, получаются таблицы вида stats_y2015_m3_u1(год 2015, месяц 3, юзер 1), в каждой таблице есть CHECK CONSTRAINT, на основной таблице висит триггер на insert который проверяет есть ли такая таблица в которую надо сделать вставку, если нет, то создает ее и делает insert. Обновление примерно 1к строк для одного юзера занимает примерно 160сек(секунд), что как бы ооочень долго, я считаю. explain analyze показывает такие данные - http://explain.depesz.com/s/fnz т.е. выполняется запрос 0.115мсек(миллисекунд), если же я запускаю вставку на сервере, то по монитору вижу, что каждый такой запрос выполняется 0.1-0.2..сек(секунд). Postgresql 9.4.0,пробовал запускать на 9.3 и на 9.2 - результат такой же. Причем заметил, что если база чистая и партицированных таблиц нет, то вставка происходит намного быстрее.
...
Рейтинг: 0 / 0
26.03.2015, 08:10
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917239
Лопата
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лопата
Участник
VerusK,
поветрие пошло -- гребсти слова в кучку. И все -- ниочом.

приведите именно тот код, который, по вашему мнению, тормозит. Весь. будем посмотреть.

И да, в обновлении (партицирующих триггерах) предусмотрена возможность смены партиции ? или по месту не двигаетесь ?
...
Рейтинг: 0 / 0
26.03.2015, 08:30
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917247
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Код который выполняется:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
UPDATE stats 
SET 
actions=(stats.actions + 0), offer_clicks=(stats.offer_clicks + 0), uniq=(stats.uniq + 0), raw=(stats.raw + 1), 
tb_uniq=(stats.tb_uniq + 0), tb_raw=(stats.tb_raw + 0), leads=(stats.leads + 0), subs=(stats.subs + 0), unsubs=(stats.unsubs + 0), 
rebills=(stats.rebills + 0), sales=(stats.sales + 0), holds=(stats.holds + 0), rejects=(stats.rejects + 0), trashes=(stats.trashes + 0),
user_lead_income=(stats.user_lead_income + 0.0), user_subs_income=(stats.user_subs_income + 0.0), 
user_rebill_income=(stats.user_rebill_income + 0.0), user_sales_income=(stats.user_sales_income + 0.0), 
user_hold_income=(stats.user_hold_income + 0.0), system_lead_income=(stats.system_lead_income + 0.0), 
system_subs_income=(stats.system_subs_income + 0.0), system_rebill_income=(stats.system_rebill_income + 0.0), 
system_sales_income=(stats.system_sales_income + 0.0), system_hold_income=(stats.system_hold_income + 0.0) 
WHERE 
stats.ts_spawn = 1426960800 AND stats.user_id = 1 AND stats.offer_targeting_id = 132 AND stats.offer_id = 123 AND 
stats.traff_type = 4 AND stats.operator_id = 0 AND stats.country_id = 113 AND 
stats.subacc_1 = '' AND stats.subacc_2 = '' AND stats.subacc_3 = '' AND stats.subacc_4 = '' AND stats.utm_source = '' AND
stats.utm_medium = '' AND stats.utm_term = '' AND stats.utm_content = '' AND stats.utm_campaign = '' AND 
stats.prelanding_id = 203 AND stats.landing_id = 0 AND stats.platform_id = 6 AND stats.platform_out_id = 76 AND 
stats.os_id = 9 AND stats.browser_id = 34
...
Рейтинг: 0 / 0
26.03.2015, 08:36
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917286
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
VerusKКод который выполняется:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
UPDATE stats 
SET 
actions=(stats.actions + 0), offer_clicks=(stats.offer_clicks + 0), uniq=(stats.uniq + 0), raw=(stats.raw + 1), 
tb_uniq=(stats.tb_uniq + 0), tb_raw=(stats.tb_raw + 0), leads=(stats.leads + 0), subs=(stats.subs + 0), unsubs=(stats.unsubs + 0), 
rebills=(stats.rebills + 0), sales=(stats.sales + 0), holds=(stats.holds + 0), rejects=(stats.rejects + 0), trashes=(stats.trashes + 0),
user_lead_income=(stats.user_lead_income + 0.0), user_subs_income=(stats.user_subs_income + 0.0), 
user_rebill_income=(stats.user_rebill_income + 0.0), user_sales_income=(stats.user_sales_income + 0.0), 
user_hold_income=(stats.user_hold_income + 0.0), system_lead_income=(stats.system_lead_income + 0.0), 
system_subs_income=(stats.system_subs_income + 0.0), system_rebill_income=(stats.system_rebill_income + 0.0), 
system_sales_income=(stats.system_sales_income + 0.0), system_hold_income=(stats.system_hold_income + 0.0) 
WHERE 
stats.ts_spawn = 1426960800 AND stats.user_id = 1 AND stats.offer_targeting_id = 132 AND stats.offer_id = 123 AND 
stats.traff_type = 4 AND stats.operator_id = 0 AND stats.country_id = 113 AND 
stats.subacc_1 = '' AND stats.subacc_2 = '' AND stats.subacc_3 = '' AND stats.subacc_4 = '' AND stats.utm_source = '' AND
stats.utm_medium = '' AND stats.utm_term = '' AND stats.utm_content = '' AND stats.utm_campaign = '' AND 
stats.prelanding_id = 203 AND stats.landing_id = 0 AND stats.platform_id = 6 AND stats.platform_out_id = 76 AND 
stats.os_id = 9 AND stats.browser_id = 34



для начала сделайте
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
explain (analyze, costs, buffers) select * from stats 
WHERE 
stats.ts_spawn = 1426960800 AND stats.user_id = 1 AND stats.offer_targeting_id = 132 AND stats.offer_id = 123 AND 
stats.traff_type = 4 AND stats.operator_id = 0 AND stats.country_id = 113 AND 
stats.subacc_1 = '' AND stats.subacc_2 = '' AND stats.subacc_3 = '' AND stats.subacc_4 = '' AND stats.utm_source = '' AND
stats.utm_medium = '' AND stats.utm_term = '' AND stats.utm_content = '' AND stats.utm_campaign = '' AND 
stats.prelanding_id = 203 AND stats.landing_id = 0 AND stats.platform_id = 6 AND stats.platform_out_id = 76 AND 
stats.os_id = 9 AND stats.browser_id = 34



и пришлите его сюда.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
26.03.2015, 09:08
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917289
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
VerusKДобрый день. Не могу понять в чем дело, копаюсь уже неделю, наверное. Есть БД в которой сейчас примерно 260 таблиц, есть такие таблицы как статистика, они унаследованы от основной таблицы статистики, т.е. в базе реализовано партицирование по времени и id юзера, получаются таблицы вида stats_y2015_m3_u1(год 2015, месяц 3, юзер 1), в каждой таблице есть CHECK CONSTRAINT, на основной таблице висит триггер на insert который проверяет есть ли такая таблица в которую надо сделать вставку, если нет, то создает ее и делает insert. Обновление примерно 1к строк для одного юзера занимает примерно 160сек(секунд), что как бы ооочень долго, я считаю. explain analyze показывает такие данные - http://explain.depesz.com/s/fnz т.е. выполняется запрос 0.115мсек(миллисекунд), если же я запускаю вставку на сервере, то по монитору вижу, что каждый такой запрос выполняется 0.1-0.2..сек(секунд). Postgresql 9.4.0,пробовал запускать на 9.3 и на 9.2 - результат такой же. Причем заметил, что если база чистая и партицированных таблиц нет, то вставка происходит намного быстрее.

А если тоже самое сделать на схеме без партиций (прямо указав с какой таблицей работаете)?
Тут есть 4 теории:

1)время планирования запроса (сколько у вас партиций сейчас)?
2)время на commit транзакции (вы все 1000 строк в одной транзакции обновляете или каждый update в своей транзакции)?
3)сетевые задержки (у вас приложение и база на одном сервере живут или на разных)?
4)диски перегруженные на запись (explain analyze никак время на commit транзакции и запись wal не учитывает).

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
26.03.2015, 09:13
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917297
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
"Append  (cost=0.00..7.35 rows=2 width=410) (actual time=0.015..0.015 rows=0 loops=1)"
"  Buffers: shared hit=2"
"  ->  Seq Scan on stats  (cost=0.00..0.00 rows=1 width=664) (actual time=0.001..0.001 rows=0 loops=1)"
"        Filter: ((ts_spawn = 1426960800) AND (user_id = 1) AND (offer_targeting_id = 132) AND (offer_id = 123) AND (traff_type = 4) AND (operator_id = 0) AND (landing_id = 0) AND (country_id = 113) AND ((subacc_1)::text = ''::text) AND ((subacc_2)::text =  (...)"
"  ->  Index Scan using stats_y2015_m3_u1_pk on stats_y2015_m3_u1  (cost=0.28..7.35 rows=1 width=155) (actual time=0.013..0.013 rows=0 loops=1)"
"        Index Cond: ((ts_spawn = 1426960800) AND (user_id = 1) AND (offer_targeting_id = 132) AND (offer_id = 123) AND (traff_type = 4) AND (operator_id = 0) AND (country_id = 113) AND ((subacc_1)::text = ''::text) AND ((subacc_2)::text = ''::text) AND ((s (...)"
"        Buffers: shared hit=2"
"Planning time: 47.748 ms"
"Execution time: 0.164 ms"



Ответ на второй пост:
Если выполнять просто на таблице:
Код: plsql
1.
2.
3.
4.
5.
"Update on stats_y2015_m3_u1 stats  (cost=0.28..7.42 rows=1 width=161) (actual time=0.016..0.016 rows=0 loops=1)"
"  ->  Index Scan using stats_y2015_m3_u1_pk on stats_y2015_m3_u1 stats  (cost=0.28..7.42 rows=1 width=161) (actual time=0.015..0.015 rows=0 loops=1)"
"        Index Cond: ((ts_spawn = 1426960800) AND (user_id = 1) AND (offer_targeting_id = 132) AND (offer_id = 123) AND (traffic_manager_id = 0) AND (traff_type = 4) AND (operator_id = 0) AND (country_id = 113) AND ((subacc_1)::text = ''::text) AND ((subacc (...)"
"Planning time: 0.675 ms"
"Execution time: 0.166 ms"



1. Партиций сейчас именно по таблице stats около 100
2. делаю общий commit, я засекал время его выполнения в коде, выполняется моментально
3. на разных серверах, но я же смотрю время выполнения запроса непосредственно на сервере.
4. если верить pg_activity диски вообще не используются, памяти на сервере 128Гб, вся база весит 35, пробовал отключить fsync - не помогло вообще никак.
...
Рейтинг: 0 / 0
26.03.2015, 09:22
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917608
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
VerusK
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
"Append  (cost=0.00..7.35 rows=2 width=410) (actual time=0.015..0.015 rows=0 loops=1)"
"  Buffers: shared hit=2"
"  ->  Seq Scan on stats  (cost=0.00..0.00 rows=1 width=664) (actual time=0.001..0.001 rows=0 loops=1)"
"        Filter: ((ts_spawn = 1426960800) AND (user_id = 1) AND (offer_targeting_id = 132) AND (offer_id = 123) AND (traff_type = 4) AND (operator_id = 0) AND (landing_id = 0) AND (country_id = 113) AND ((subacc_1)::text = ''::text) AND ((subacc_2)::text =  (...)"
"  ->  Index Scan using stats_y2015_m3_u1_pk on stats_y2015_m3_u1  (cost=0.28..7.35 rows=1 width=155) (actual time=0.013..0.013 rows=0 loops=1)"
"        Index Cond: ((ts_spawn = 1426960800) AND (user_id = 1) AND (offer_targeting_id = 132) AND (offer_id = 123) AND (traff_type = 4) AND (operator_id = 0) AND (country_id = 113) AND ((subacc_1)::text = ''::text) AND ((subacc_2)::text = ''::text) AND ((s (...)"
"        Buffers: shared hit=2"
"Planning time: 47.748 ms"
"Execution time: 0.164 ms"



Ответ на второй пост:
Если выполнять просто на таблице:
Код: plsql
1.
2.
3.
4.
5.
"Update on stats_y2015_m3_u1 stats  (cost=0.28..7.42 rows=1 width=161) (actual time=0.016..0.016 rows=0 loops=1)"
"  ->  Index Scan using stats_y2015_m3_u1_pk on stats_y2015_m3_u1 stats  (cost=0.28..7.42 rows=1 width=161) (actual time=0.015..0.015 rows=0 loops=1)"
"        Index Cond: ((ts_spawn = 1426960800) AND (user_id = 1) AND (offer_targeting_id = 132) AND (offer_id = 123) AND (traffic_manager_id = 0) AND (traff_type = 4) AND (operator_id = 0) AND (country_id = 113) AND ((subacc_1)::text = ''::text) AND ((subacc (...)"
"Planning time: 0.675 ms"
"Execution time: 0.166 ms"



1. Партиций сейчас именно по таблице stats около 100
2. делаю общий commit, я засекал время его выполнения в коде, выполняется моментально
3. на разных серверах, но я же смотрю время выполнения запроса непосредственно на сервере.
4. если верить pg_activity диски вообще не используются, памяти на сервере 128Гб, вся база весит 35, пробовал отключить fsync - не помогло вообще никак.

1)это в пределах разумного
2)это хорошо
4)тоже очень хорошо...

а вот про 3 - а как собственно вы смотрите время выплнения запроса непосредственно на сервере?
попробуйте включить log_min_duration_statement=0 и прислать то что записалось в лог для одного из ваших проблемных запросов.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
26.03.2015, 13:03
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917679
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Maxim Boguk, вот, выдернул из лога только что

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
015-03-26 10:16:04 UTC, LOG:  duration: 150.878 ms  statement: 
UPDATE stats SET actions=(stats.actions + 0), 
offer_clicks=(stats.offer_clicks + 0), uniq=(stats.uniq + 1), raw=(stats.raw + 0), tb_uniq=(stats.tb_uniq +0), 
tb_raw=(stats.tb_raw + 0), leads=(stats.leads + 0), subs=(stats.subs + 0), unsubs=(stats.unsubs + 0), 
rebills=(stats.rebills + 0), sales=(stats.sales + 0), 
holds=(stats.holds + 0), rejects=(stats.rejects + 0), trashes=(stats.trashes + 0), user_lead_income=(stats.user_lead_income + 0.0), 
user_subs_income=(stats.user_subs_income + 0.0), user_rebill_income=(stats.user_rebill_income + 0.0), 
user_sales_income=(stats.user_sales_income + 0.0), user_hold_income=(stats.user_hold_income + 0.0), 
system_lead_income=(stats.system_lead_income + 0.0), system_subs_income=(stats.system_subs_income + 0.0), 
system_rebill_income=(stats.system_rebill_income + 0.0), system_sales_income=(stats.system_sales_income + 0.0), 
system_hold_income=(stats.system_hold_income + 0.0) 
WHERE 
stats.ts_spawn = 1427364000 AND stats.user_id = 1 AND stats.offer_targeting_id = 124 AND stats.offer_id = 135 AND stats.traffic_manager_id = 0 AND 
stats.traff_type = 2 AND stats.operator_id = 0 AND stats.country_id = 192 AND 
stats.subacc_1 = '' AND stats.subacc_2 = '' AND stats.subacc_3 = '' AND 
stats.subacc_4 = '' AND stats.utm_source = '' AND stats.utm_medium = '' AND stats.utm_term = '' AND 
stats.utm_content = '' AND stats.utm_campaign = '' AND stats.prelanding_id = 223 AND stats.landing_id = 345 AND 
stats.platform_id = 10 AND stats.platform_out_id = 15 AND stats.os_id = 5 AND stats.browser_id = 34
...
Рейтинг: 0 / 0
26.03.2015, 13:41
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917842
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
у тебя для апдейта 1000 строк, вызывается 100 апдейтов???
нельзя пакетно?
...
Рейтинг: 0 / 0
26.03.2015, 15:44
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917845
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
Ivan Durakу тебя для апдейта 1000 строк, вызывается 100 апдейтов???
нельзя пакетно?
в смысле всю свою статистику инсертишь в лог. А раз в N секунд из лога пакетно группируешь и обновляешь таблицы статистики,
а лог очищаешь
...
Рейтинг: 0 / 0
26.03.2015, 15:47
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38917924
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Ivan Durak, это 1000 уже сгруппированных уникальных по PK строк, я выполняю update, insert, update на случай если строки не было.
...
Рейтинг: 0 / 0
26.03.2015, 16:38
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38918447
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
VerusKIvan Durak, это 1000 уже сгруппированных уникальных по PK строк, я выполняю update, insert, update на случай если строки не было.
Где же тут твоя тысяча???
Есть есть уже 1000 сгруппированных то апдейт будет такой:

UPDATE stats s set actions = s.actions + coalesce(t.actions, 0), ... etc
FROM TableWith1000Rows t
WHERE s.pk = t.pk;
----------------------
конечно тут даже не 1000, на 1000 врядли будет выйгрыш, тут еще лучше сразу миллионами обновлять - чем больше тем лучше
...
Рейтинг: 0 / 0
27.03.2015, 09:38
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38918456
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Ivan Durak, этих строк может не быть в базе. Если нет хотя бы одной, значит надо сделать insert, но сфейлится весь запрос. Как сделать upsert?
...
Рейтинг: 0 / 0
27.03.2015, 09:43
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38918603
?Ы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?Ы
Гость
VerusK Как сделать upsert?
Код: sql
1.
2.
with upd AS (update ... returning ...)
INSERT INTO .... WHERE NOT EXISTS (SELECT 1 FROM upd WHERE ...)
...
Рейтинг: 0 / 0
27.03.2015, 10:59
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38918762
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
VerusKIvan Durak, этих строк может не быть в базе. Если нет хотя бы одной, значит надо сделать insert, но сфейлится весь запрос. Как сделать upsert?

не сфейлится с чего вдруг? Обновит что есть.

А после апдейта делай инсерт, хочешь как в посте выше,
хочешь отдельно

Insert into stats
select t.*
from TableWith1000Rows t
left join stats s on s.pk=t.pk
where s.pk is null;
...
Рейтинг: 0 / 0
27.03.2015, 11:47
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921040
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Ivan Durak, проблема то в том что именно запрос на апдейт одной строки выполняется долго(см. первый пост), тут экономия получится только на больших объемах, но в целом хочется понять почему такая проблема с апдейтом. Из-за большого кол-ва партиций или дело еще в чем-то?
...
Рейтинг: 0 / 0
30.03.2015, 12:52
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921086
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
VerusKIvan Durak, проблема то в том что именно запрос на апдейт одной строки выполняется долго(см. первый пост), тут экономия получится только на больших объемах, но в целом хочется понять почему такая проблема с апдейтом. Из-за большого кол-ва партиций или дело еще в чем-то?
duration: 150.878 ms
Куда быстрее-то!?
Проблема таки в том что не надо апдейтить по одной!
...
Рейтинг: 0 / 0
30.03.2015, 13:18
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921268
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
VerusKIvan Durak, проблема то в том что именно запрос на апдейт одной строки выполняется долго(см. первый пост), тут экономия получится только на больших объемах, но в целом хочется понять почему такая проблема с апдейтом. Из-за большого кол-ва партиций или дело еще в чем-то?

у вас теже самые записи кто то еще паралелльно не может обновлять?
очень уж похоже на блокировки.

Попробуйте (временно) поставить deadlock_timeout=100ms + log_lock_waits=on
и посмотрите на логи на предмет не были ли ожиданий локов на ваших update.


--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
30.03.2015, 15:12
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921669
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Maxim Boguk, была такая мысль уже, проверял, локов нет. Думаю остановлюсь на идее делать только insert, буду группировать и каждые n минут сбрасывать в базу записи. Получится больше строк, но думаю это не критично в данный момент.
...
Рейтинг: 0 / 0
30.03.2015, 21:20
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921672
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Maxim Boguk, вопрос в догонку - вы тоже считаете, что 150мсек это нормально на такие запросы и на мою структуру? :)
...
Рейтинг: 0 / 0
30.03.2015, 21:25
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921682
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

Вы делаете UPDATE на мастер-таблицу, так?
А в партиции запрос спускается через триггер, да?
...
Рейтинг: 0 / 0
30.03.2015, 21:39
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921720
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov, в партиции спускается только insert, триггер стоит на insert, а update понимает через check constraint по полям в PK
...
Рейтинг: 0 / 0
30.03.2015, 22:53
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921740
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

Чудно.
Попробуйте поставить auto_explain и включить его кратковременно.
...
Рейтинг: 0 / 0
30.03.2015, 23:30
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921793
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
VerusKMaxim Boguk, вопрос в догонку - вы тоже считаете, что 150мсек это нормально на такие запросы и на мою структуру? :)

Ненормально по времени на пару порядков.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
31.03.2015, 02:56
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921839
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

выкладываю парочку запросов, один в 2 раза быстрее получился, но такое бывает иногда, с утра меньше нагрузки.
Длинный:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
2015-03-31 05:02:31 UTC 64255 LOG:  duration: 151.565 ms  plan:
        Query Text: UPDATE stats SET actions=(stats.actions + 0), offer_clicks=(stats.offer_clicks + 0), uniq=(stats.uniq + 1), raw=(stats.raw + 0), tb_uniq=(stats.tb_uniq + 0), tb_raw=(stats.tb_raw + 0), leads=(stats.leads + 0), subs=(stats.subs + 0), unsubs=(stats.unsubs + 0), rebills=(stats.rebills + 0), sales=(stats.sales + 0), holds=(stats.holds + 0), rejects=(stats.rejects + 0), trashes=(stats.trashes + 0), user_lead_income=(stats.user_lead_income + 0.0), user_subs_income=(stats.user_subs_income + 0.0), user_rebill_income=(stats.user_rebill_income + 0.0), user_sales_income=(stats.user_sales_income + 0.0), user_hold_income=(stats.user_hold_income + 0.0), system_lead_income=(stats.system_lead_income + 0.0), system_subs_income=(stats.system_subs_income + 0.0), system_rebill_income=(stats.system_rebill_income + 0.0), system_sales_income=(stats.system_sales_income + 0.0), system_hold_income=(stats.system_hold_income + 0.0) WHERE stats.ts_spawn = 1427778000 AND stats.user_id = 8 AND stats.offer_targeting_id = 124 AND stats.offer_id = 135 AND stats.traffic_manager_id =0 AND stats.traff_type = 2 AND stats.operator_id = 0 AND stats.country_id = 192 AND stats.subacc_1 = '' AND stats.subacc_2 = '' AND stats.subacc_3 = '' AND stats.subacc_4 = '' AND stats.utm_source = '' AND stats.utm_medium = '' AND stats.utm_term = '' AND stats.utm_content = '' AND stats.utm_campaign = '' AND stats.prelanding_id = 222 AND stats.landing_id = 345 AND stats.platform_id = 10 AND stats.platform_out_id = 15 AND stats.os_id = 5 AND stats.browser_id = 34
        Update on stats  (cost=0.00..7.76 rows=2 width=420) (actual time=151.564..151.564 rows=0 loops=1)
          ->  Seq Scan on stats  (cost=0.00..0.07 rows=1 width=670) (actual time=0.000..0.000 rows=0 loops=1)
                Filter: ((ts_spawn = 1427778000) AND (user_id = 8) AND (offer_targeting_id = 124) AND (offer_id = 135) AND (traffic_manager_id = 0) AND (operator_id = 0) AND (traff_type = 2) AND (country_id = 192) AND ((subacc_1)::text = ''::text) AND ((subacc_2)::text = ''::text) AND ((subacc_3)::text = ''::text) AND ((subacc_4)::text = ''::text) AND ((utm_source)::text = ''::text) AND ((utm_medium)::text = ''::text) AND ((utm_term)::text = ''::text) AND ((utm_content)::text = ''::text) AND ((utm_campaign)::text = ''::text) AND (prelanding_id = 222) AND (landing_id = 345) AND (platform_id = 10) AND (platform_out_id = 15) AND (os_id = 5) AND (browser_id = 34))
          ->  Index Scan using stats_y2015_m3_u8_pk on stats_y2015_m3_u8  (cost=0.55..7.69 rows=1 width=171) (actual time=0.218..0.221 rows=1 loops=1)
                Index Cond: ((ts_spawn = 1427778000) AND (user_id = 8) AND (offer_targeting_id = 124) AND (offer_id = 135) AND (traffic_manager_id = 0) AND (traff_type = 2) AND (operator_id = 0) AND (country_id = 192) AND ((subacc_1)::text = ''::text) AND ((subacc_2)::text = ''::text) AND ((subacc_3)::text = ''::text) AND ((subacc_4)::text = ''::text) AND ((utm_source)::text = ''::text) AND ((utm_medium)::text = ''::text) AND ((utm_term)::text = ''::text) AND ((utm_content)::text = ''::text) AND ((utm_campaign)::text = ''::text) AND (prelanding_id = 222) AND (landing_id = 345) AND (platform_id = 10) AND (platform_out_id = 15) AND (os_id = 5) AND (browser_id = 34))



и побыстрее:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
2015-03-31 05:02:31 UTC 64264 LOG:  duration: 62.925 ms  plan:
        Query Text: UPDATE stats SET actions=(stats.actions + 0), offer_clicks=(stats.offer_clicks + 0), uniq=(stats.uniq + 1), raw=(stats.raw + 0), tb_uniq=(stats.tb_uniq + 0), tb_raw=(stats.tb_raw + 0), leads=(stats.leads + 0), subs=(stats.subs + 0), unsubs=(stats.unsubs + 0), rebills=(stats.rebills + 0), sales=(stats.sales + 0), holds=(stats.holds + 0), rejects=(stats.rejects + 0), trashes=(stats.trashes + 0), user_lead_income=(stats.user_lead_income + 0.0), user_subs_income=(stats.user_subs_income + 0.0), user_rebill_income=(stats.user_rebill_income + 0.0), user_sales_income=(stats.user_sales_income + 0.0), user_hold_income=(stats.user_hold_income + 0.0), system_lead_income=(stats.system_lead_income + 0.0), system_subs_income=(stats.system_subs_income + 0.0), system_rebill_income=(stats.system_rebill_income + 0.0), system_sales_income=(stats.system_sales_income + 0.0), system_hold_income=(stats.system_hold_income + 0.0) WHERE stats.ts_spawn = 1427778000 AND stats.user_id = 32 AND stats.offer_targeting_id = 82 AND stats.offer_id = 22 AND stats.traffic_manager_id = 0 AND stats.traff_type = 2 AND stats.operator_id = 0 AND stats.country_id = 192 AND stats.subacc_1 = '' AND stats.subacc_2 = '' AND stats.subacc_3 = '' ANDstats.subacc_4 = '' AND stats.utm_source = '' AND stats.utm_medium = '' AND stats.utm_term = '' AND stats.utm_content = '' AND stats.utm_campaign = '4763' AND stats.prelanding_id = 34 AND stats.landing_id = 66 AND stats.platform_id = 16 AND stats.platform_out_id = 68 AND stats.os_id = 4 AND stats.browser_id = 34
        Update on stats  (cost=0.00..7.76 rows=2 width=418) (actual time=62.923..62.923 rows=0 loops=1)
          ->  Seq Scan on stats  (cost=0.00..0.07 rows=1 width=670) (actual time=0.002..0.002 rows=0 loops=1)
                Filter: ((ts_spawn = 1427778000) AND (user_id = 32) AND (offer_targeting_id = 82) AND (offer_id = 22) AND (traffic_manager_id = 0) AND (operator_id = 0) AND (traff_type = 2) AND (country_id = 192) AND ((subacc_1)::text = ''::text) AND ((subacc_2)::text = ''::text) AND ((subacc_3)::text = ''::text) AND ((subacc_4)::text = ''::text) AND ((utm_medium)::text = ''::text) AND ((utm_term)::text = ''::text) AND ((utm_content)::text = ''::text) AND ((utm_source)::text = ''::text) AND ((utm_campaign)::text = '4763'::text) AND (prelanding_id = 34) AND (browser_id = 34) AND (landing_id = 66) AND (platform_id = 16) AND (platform_out_id = 68) AND (os_id = 4))
          ->  Index Scan using stats_y2015_m3_u32_pk on stats_y2015_m3_u32  (cost=0.55..7.69 rows=1 width=166) (actual time=0.219..0.222 rows=1 loops=1)
                Index Cond: ((ts_spawn = 1427778000) AND (user_id = 32) AND (offer_targeting_id = 82) AND (offer_id = 22) AND (traffic_manager_id = 0) AND(traff_type = 2) AND (operator_id = 0) AND (country_id = 192) AND ((subacc_1)::text = ''::text) AND ((subacc_2)::text = ''::text) AND ((subacc_3)::text = ''::text) AND ((subacc_4)::text = ''::text) AND ((utm_source)::text = ''::text) AND ((utm_medium)::text = ''::text) AND ((utm_term)::text = ''::text) AND ((utm_content)::text = ''::text) AND ((utm_campaign)::text = '4763'::text) AND (prelanding_id = 34) AND (landing_id = 66) AND (platform_id = 16) AND (platform_out_id = 68) AND (os_id = 4) AND (browser_id = 34))



Меня смущает, что в обоих случаях actual time=0.218..0.221, вот такое время на апдейт меня устраивает. Видимо все остальное время работает планировщик? о_О
...
Рейтинг: 0 / 0
31.03.2015, 08:18
| Ответить | Цитировать | Написать  
25 сообщений из 65, страница 1 из 3
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Быстрый запрос в explain analyze но медленный по факту
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38921672&tid=1998077]:
 0ms
get settings:
 6ms
get forum list:
 12ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 155ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 44ms
get tp. blocked users:
 1ms
others: 241ms
total:  474ms
созд. / загр.: 474ms
x
x
Закрыть


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