http://www.youtube.com/watch?v=vTTzwJsH
SELECT activity_activityevent.id, activity_activityevent.user_id, activity_activityevent.added_on FROM activity_activityevent WHERE activity_activityevent.user_id IN ( SELECT U0.user_id FROM profile U0 INNER JOIN profile_friends U1 ON U0.user_id = U1.to_profile_id WHERE U1.from_profile_id = 5 ) ORDER BY activity_activityevent.added_on DESC LIMIT 10( Read more... )
[NOTICE@1252216599.924163] mcm_storage_cmd():3339: unable to store value: add [NOTICE@1252216599.924494] mcm_storage_cmd():3339: unable to store value: add [NOTICE@1252216599.924764] mcm_storage_cmd():3339: unable to store value: add [NOTICE@1252216599.925048] mcm_storage_cmd():3339: unable to store value: add
Соответственно, кэширование не работает. Гугление этих ошибок никакого вразумительного ответа не дает. Видимо, придется откатываться к более медленному pure-python модулю memcache.
Искусственный интеллект PostgreSQL начинает задалбывать. Есть долгий запрос с несколькими JOIN'ами. В паре JOIN'ов не используется индекс, вместо этого Postgres ищет 1000 значений в таблице из миллиона записей методом seq scan. Развернул дамп базы локально на той же версии postgres. Сделал VACUUM ANALYZE для трех таблиц, которые используются в JOIN'ах. Postgres начал использовать индекс и время выполнения запроса уменьшилось более чем в два раза. На production VACUUM ANALYZE тех же таблиц ни к чему не приводит, запрос выполняется все так же медленно.
Может быть ему вообще запретить метод seq scan?
CREATE OR REPLACE VIEW pg_table_nonindex_x AS SELECT x1.table_in_trouble, pg_relation_size(x1.table_in_trouble) AS sz_n_byts, x1.seq_scan, x1.idx_scan, CASE WHEN pg_relation_size(x1.table_in_trouble) > 500000000 THEN 'Exceeds 500 megs, too large to count in a view. For a count, count individually'::text ELSE count(x1.table_in_trouble)::text END AS tbl_rec_count, x1.priority FROM ( SELECT (schemaname::text || '.'::text) || relname::text AS table_in_trouble, seq_scan, idx_scan, CASE WHEN (seq_scan - idx_scan) < 500 THEN 'Minor Problem'::text WHEN (seq_scan - idx_scan) >= 500 AND (seq_scan - idx_scan) < 2500 THEN 'Major Problem'::text WHEN (seq_scan - idx_scan) >= 2500 THEN 'Extreme Problem'::text ELSE NULL::text END AS priority FROM pg_stat_all_tables WHERE seq_scan > idx_scan AND schemaname != 'pg_catalog'::name AND seq_scan > 100) x1 GROUP BY x1.table_in_trouble, x1.seq_scan, x1.idx_scan, x1.priority ORDER BY x1.priority DESC, x1.seq_scan ; SELECT * FROM pg_table_nonindex_x;
He would also have to pay a fine of $250,000 (£150,000) for each of the two charges.
Good thing he didn't download any music!
![]() | Вы читаете журнал Вход Создать аккаунт в ЖЖ Подробности |