false типа?

угу, правда waiting - это флаг, что воркер ожидает освобождения блокировки

Мне нужно записать дату изменения при обновления записи В доке pg описано before update и after update Когда мне дату то записывать до или после? Есть какая то серьезная разница?

Именно дату и именно изменения? Я бы одним запросом вместе с данными делал безо всяких триггеров, ибо тормоза будут гарантированно. А вот порядок тормозов - это надо смотреть.

ОЗУ есть, процессор не так нагружен тоже Зато висят процессы на INSERT с каких-то воркеров, что пишут в базу

Ну индексы же ковыряет в один проц

А, там виртулка какая-то. Тогда хз.

Именно дату и именно изменения? Я бы одним запросом вместе с данными делал безо всяких триггеров, ибо тормоза будут гарантированно. А вот порядок тормозов - это надо смотреть.

Ок, спасибо.

UUID против BIGINT - замерял кто нибудь скорость?

Нашел только такую статью. Но она 2012 года http://softblog.violet-tape.ru/2012/06/06/guid-as-pk/

Может что нибудь изменилось

а зачем вам uuid? стоит начать с этого

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

очень много весит все это, с индексами даже страшно представлять

в качестве PK таблицы лицевых интернет счетов.

Или сделать отдельную колонку просто?

очень много весит все это, с индексами даже страшно представлять

128 бит против 64

UUID против BIGINT - замерял кто нибудь скорость?

http://gosimple.me/postgresql-primary-key-type-analysis

128 бит против 64

арифметика простая. Представьте, к примеру, 8 внешних включей уидов. И 8 внешних ключей интов. И миллионы записей во всех связанных таблицах

UUID против BIGINT - замерял кто нибудь скорость?

Во сколько раз uuid длиннее bigint, во столько и поиск по индексу медленнее

Поиск как был log(n) так и останется

Только размер индекса измениться

неплохой повод устроить холивар)

Константа немного вырастет просто. Возможно несущественно

если и тот и тот в кэш помещаются

арифметика простая. Представьте, к примеру, 8 внешних включей уидов. И 8 внешних ключей интов. И миллионы записей во всех связанных таблицах

Это же... Все тот же самый O(n)

Не-не-не! https://postgrespro.ru/docs/postgrespro/9.6/datatype-uuid Тыц01 В Postgres Pro встроены функции хранения и сравнения идентификаторов UUID, но нет внутренней функции генерирования UUID, потому что не существует какого-то единственного алгоритма, подходящего для всех приложений. Следствие тыц01 Сгенерировать UUID можно с помощью дополнительного модуля uuid-ossp, в котором реализованы несколько стандартных алгоритмов, а можно воспользоваться модулем pgcrypto, где тоже есть функция генерирования случайных UUID. Кроме того, можно сделать это в клиентском приложении или в другой библиотеке, подключённой на стороне сервера.

Во сколько раз uuid длиннее bigint, во столько и поиск по индексу медленнее

тут не в длине дело, а в том что uuid будет раскидан по всему диску неупорядоченно.

Количество слоёв в индексе и правда log, но вот сравнивать нужно в два раза большие по длине в индексе значения. Log это про сравнение с сексканом. Или я не прав?

Т.е. налиТСо дополнительное рукоблудие в плане установки контрибов (а оные контрибы не всегда ставятся вместе с сервером) и последующего создания соответствующего EXTENTION-а в каждой базе, где этот UUID нужен.

Вы правда думаете, что боттлнек будет из-за того, что процессор будет сравнивать в два раза большие значения?

Типа загрузить один регистр - нормально, два - уже медленно

Регистры же самые медленные

Фрагментация индекса пока выглядит куда страшнее

А мне кажется, что не в регистрах дело, а в том, что с диска придётся считать в два раза больше данных. Не зависимо индекс это или таблица

Сколько бит занимает целиком запись в таблице? Лишние 64 бит будут сильно влиять на производительность? Серьезно?

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

А то чего он столько занимает, а мы за диск платим

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

toast

Какая разница? Читать-то надо

Да, до них же надо добраться, прочитав другие кортежи. Я это к тому, что при считывании из нескольких миллионов строк uuid и guid разница становится очень заметна. Проверьте

Зачем вы их храните строками

Кого, простите? Строки в таблице?

Это же просто шестнадцать байт

Uuid

Вы меня не поняли. Возьмите создайте две таблице на 1кк каждая с одним столбцов. В одной будет uuid, в другой bigint. И сравните скорость запросов даже по равенству первичному ключу

В реальном ворклоаде никто не выбирает просто uuid и просто бигинты

Не понял вас. В плане не выбирают?

В плане в реальном мире никогда нет таблицы из одних первичных ключей

Запись всегда весит в разы больше первичного ключа

Но есть запросы по покрывающим индексам

Относительные значения тоже как правило ни на что не влияют

Потому что разницы между одной и двумя миллисекундами нет

И шансы того, что боттлнек будет именно в uuid - они невелики

У uuid есть приятные свойства, позволяющие не хранить, переносить и синхронизировать счетчики в больших системах

имхо основной профит uuid-ов в том, что их можно генерировать в разных несвязанных базах и чтобы они при этом не пересекались. Если база единственная, то смысла их использовать в общем-то немного

Я просто говорю, что uuid медленнее bigint и на больших таблицах, где отбор сложнее, чем равенство первичному ключу - это сказывается. Сильно

Отбор сложнее будет очевидно происходить по другим столбцам

"нам четные ууиды, пожалуйста"

Зачем? Ну это нереальные все кейсы

Нам uuid,которые встречаются во второй таблице и не встречаются в третьей, которых атрибут такой-то. Вполне жизненный кейс

Так у ууидов же в постгресе abbreviated key compare, нет?

Он сравнивается префиксом как бигинтом вначале

Но за счёт длины сравнивается дольше, так как поднимать с диска в два раза больше. Я не прав?

И поднимать придётся не один uuid

Нам uuid,которые встречаются во второй таблице и не встречаются в третьей, которых атрибут такой-то. Вполне жизненный кейс

Атрибут такой-то - это и есть другие столбцы. Джойны очевидно будут по индексам идти, да, просадка будет, но не настолько демоническая же

Атрибут такой-то - это и есть другие столбцы. Джойны очевидно будут по индексам идти, да, просадка будет, но не настолько демоническая же

У меня в одной схеме живут такие конструкции. Я вот уже хочу bigint, но там нужны именно uuid((

Атрибут такой-то - это и есть другие столбцы. Джойны очевидно будут по индексам идти, да, просадка будет, но не настолько демоническая же

А ты проверь сначала на хотя бы таблицах размером в 100Гб и 10млн строк.

я вам говорю, это боль. Особенно в условиях ограниченного дискового пространства

ERROR: S client not available

подитог: BIGSERIAL

UIID только для наследуемых таблиц

не сервере пг 52% места занято и поэтому не работает вакум фулл. Можно как-то сделать фулл вакум не увеличивая место на диске?

не сервере пг 52% места занято и поэтому не работает вакум фулл. Можно как-то сделать фулл вакум не увеличивая место на диске?

Подключить другой диск, сделать на нем table space и вынести на него что-нибудь, например часть индексов

Подключить другой диск, сделать на нем table space и вынести на него что-нибудь, например часть индексов

ох окей, так и подозревал

не сервере пг 52% места занято и поэтому не работает вакум фулл. Можно как-то сделать фулл вакум не увеличивая место на диске?

https://github.com/reorg/pg_repack

не сервере пг 52% места занято и поэтому не работает вакум фулл. Можно как-то сделать фулл вакум не увеличивая место на диске?

А что размер самой большой таблицы больше 50%

А что размер самой большой таблицы больше 50%

неа, меньше. Индивидуально оно вакумилось, а все сразу нет

неа, меньше. Индивидуально оно вакумилось, а все сразу нет

странно

https://github.com/reorg/pg_repack

у меня 8мес назад как раз и сдох RAID когда я эту баланду запустил с целью повакумить с 73% загруженного места, не спасибо :)

не сервере пг 52% места занято и поэтому не работает вакум фулл. Можно как-то сделать фулл вакум не увеличивая место на диске?

Потаблично делать вакуум фулл.

неа, меньше. Индивидуально оно вакумилось, а все сразу нет

вы наверное пытаетесь в несколько потоков?

Потаблично делать вакуум фулл.

угу так можно, но думаю не остановит ли это автовакум однажды?

угу так можно, но думаю не остановит ли это автовакум однажды?

Не знаю, но так "развлекались" ребята на одном проекте... ПАтАмуШтА "одарённые" начальнЕГЕ "успешно" сокращали затраты на инфраструктуру. Пока этого начальнЕГа не ткнули носом: а завтра (грубо утрируя) усё! Проект помре, пАтАмуШтА дисков нет и неизвестно.

Не знаю, но так "развлекались" ребята на одном проекте... ПАтАмуШтА "одарённые" начальнЕГЕ "успешно" сокращали затраты на инфраструктуру. Пока этого начальнЕГа не ткнули носом: а завтра (грубо утрируя) усё! Проект помре, пАтАмуШтА дисков нет и неизвестно.

мне просто денег не хватает - железо арендованное, и конфигов дедик серверов с SSD уже крупнее не нахожу...

есть вариант компрессию еще включить думаю

угу так можно, но думаю не остановит ли это автовакум однажды?

вакуум фулл эксклюзивно блокирует табличку. Соответственно, автовакуум, по идее, должен пройти мимо, не трогая её.

Нашел такое решение. CREATE OR REPLACE FUNCTION update_modified_column() RETURNS TRIGGER AS $$ BEGIN IF row(NEW.*) IS DISTINCT FROM row(OLD.*) THEN NEW.ud = now(); RETURN NEW; ELSE RETURN OLD; END IF; END; $$ language 'plpgsql'; но прочел что триггеры замедляют работу. Насколько сильно снижается. Стоит ли заморачиваться?

pgbench говорит 13619 tps с триггером против 14297 без триггера

Странно

Очему меньше то?

Я думал от том что больше, вопрос размера этого "больше". Но судя по стате все в триггеры надо пихать )

pgbench говорит 13619 tps с триггером против 14297 без триггера

Ваще чудеса! o_O

pgbench говорит 13619 tps с триггером против 14297 без триггера

сколько раз прогнали тест?

Кратенько - по 100 секунд pgbench -c 20 -j 4 -P 1 -T 100 postgres

Очему меньше то?

TPS (transactions per second) с триггером меньше, т.е. скорость работы меньше, запросы выполняются дольше.

ааа ? тупанул

тогда все уложилось в голову

TPS (transactions per second) с триггером меньше, т.е. скорость работы меньше, запросы выполняются дольше.

Блин, Серёга, ну нельзя же так! :(

ааа ? тупанул

Не ты один.

ато у меня крыша съезжать медленно стала, пытаясь понять: "КАК?"

ато у меня крыша съезжать медленно стала, пытаясь понять: "КАК?"

Ага, есть такое. Переработал, однозначно. :)

@SergeyPpro спасибо за бенчмарк