Как стать автором
Обновить

Как мы решили проблему с памятью в PostgreSQL, не добавив ни байта

Время на прочтение3 мин
Количество просмотров16K
Всего голосов 37: ↑34 и ↓3+31
Комментарии12

Комментарии 12

Вижу, что перевод, но все же спрошу.


  1. Не будет ли такой подход вызывать сильную фрагментацию данных и тормозов с VACUUM?
  2. Почему бы не добавить индексированное поле, в котором хранится md5, с ограничением уникальности? При вставке данных можно просто отбрасывать уже существующие (делать UPSERT), тогда и чистить не придется.
  3. Нет ли опасности удалить что-то нужное при коллизии хешей?
НЛО прилетело и опубликовало эту надпись здесь
Ну, тогда будет скучно и неинтересно. Нельзя будет написать целую статью о том, как удалять то, что в нормальной БД вообще не должно появляться.
По-моему нужно было остановиться на md5 и дальше тюнить саму базу.

Подобные костыли до добра не доводят.
Я вообще не понимаю зачем тут pgcrypto, если postgres может сам сконвертировать:
select md5('my data')::uuid

Сравнить по скорости к сожалению не могу
Картинка с графиком места на диске не грузится из-за роскомпозора, стоит перезалить на habrastorage.org
А так?
Ага, починилось.

Или задача сильно вырвана из контекста или в изначальной базе явные проблемы проектирования.

У вас очень странный адрес оригинала статьи.
Вот ссылка на правильный
Наша – через NoBlockMe. Не работает?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий