определённой таблице?
а вам зачем?
Есть мелкая горячая табличка с каунтерами и если сбоку пустить длинную транзакцию - таблица пухнет. Приложение достало counter, увеличило на 1. При этом время select'а по ней растёт линейно. Хочу проверить гипотезу что честный index modification будет суммарно для приложения дешевле чем скачки по HOT-цепочке.
скачки по hot-цепочке делаются внутри странички в памяти - это по сути cputime, а вот index modification это честный iotime - который медленее чем работа cpu, быстрее быть не должно. но гипотезы на то и есть чтобы их подтверждать или опровергать))) случай с апдейтом значения в пк должен делать облом hot, так что можно попробовать
Но эффективно-то update pk не произойдёт. Постгрес это пронюхает и пойдёт по HOT-варианту или будет тупо менять индекс?
Дорожэ будет, поскольку оба тапла придётся через индэкс доставать.
да вы правы, hot anyway
Ну так 2 тапла, ну 4 блока максимум, а не 8M heap'а по HOT chain просматривать
Спасибо огромное! Пойду проиндексирую всё вдоль и поперёк.
скиньте хоть цифры потом сюда)))
Спецмифический случай, но попробую.
И да, основная причина того, что в постгресе нет способа запретить HOT UPDATE -- это то, что HOT UPDATE, когда возможэн, просто во всём быстрее классического UPDATE.
Это average time с точки зрения приложения. В 15 часов с HOT, в 16:20 с индексом на (id, counter). С точки зрения Postgres в обоих случаях oldest xid переваливает за 2-3 миллиона и размер таблички раздувает с 80к до 10Mb
время на оси y в ms?
Нет, в секундах. Нормальное время выполнения 50-60ms
Обсуждают сегодня