Спасибо за интерес к статье и столь содержательные замечания.
Согласен, pg_relation_size(...) / 8192 не является строгим доказательством того, что таблица физически состоит из страниц. Использовал лишь как удобную демонстрацию того, что объем данных кратен размеру страницы (8 KB по умолчанию). Корректнее будет уточнить, что таблицы PostgreSQL действительно состоят из страниц фиксированного размера, и это подтверждается документацией и внутренней организацией heap-файлов, а приведенный запрос иллюстрация, а не proof. С вашего разрешения я немного скорректирую формулировку в статье по следам вашего комментария.
Да, теримн может ввести в заблуждение. Точнее будет сказать:
ctid идентификатор местоположения tuple внутри heap-файла, который включает (block_number, offset_in_page).
Это не абсолютный смещённый байтовый адрес, а координаты внутри структуры heap. Благодаря этму PostgreSQL может найти конкретный tuple без индексации, но сам по себе ctid не указывает положение в виде числа байт. Согласен, что термин стоило уточнить, поправлю.
3. PostgreSQL испльзует механизм TOAST (The Oversized-Attribute Storage Technique). Если строка превышает лимит содержание просто выносятся во внешнее TOAST-хранилище, а в tuple остаётся указатель. Поэтому одна tuple всегда помещается в страницу, а большие значения «разамзываются» по TOAST-страницам. Подробнее можно посмотреть в первоисточнике https://www.postgresql.org/docs/current/storage-toast.htm
4. нет никакой карты "просто страниц" и в ней нет необходимости. Таблица просто хранится в виде линейного файла, состоящего из блоков по 8 КБ внутри heap.Номер страницы это её положение внутри файла. Для более глубокого разбора тоже придется обращаться к первоисточнику https://www.postgresql.org/docs/current/storage-file-layout.html
5. Тут вы верно поняли про FSM и VM они не яаляются частью реализации MVCC, состяния легко и просто перезаписываются без версионирования и это ожидаемое поведение продукта. Идея в том, что они просто подсказки для оптимизации запросов, а не критически важный источник истины. В худшем случае PostgreSQL просто сделает лишний IO и перексанирует страницы.
Спасибо за подробный комментарий. Попробую уточнить, в чём, на мой взгляд, произошло недопонимание.
Идею “созидающий сначала разрушает” высказывал ещё Ницше, и нет доказательств, что она применима к компании.
Разумеется, идея не нова от Шумпетера и Клейтона Кристенсена до Мокира и Талеба её рассматривали в разных контекстах. Но речь не о философской максиме, а о прикладном управленческом паттерне. Компании действительно вынуждены «разрушать» свои старые решения — не в метафизическом, а в инженерном смысле. Примеры есть у всех крупных игроков: Amazon заменил monolith S3 control plane на микросервисы, Netflix несколько раз переписывал систему рекомендаций, а Microsoft закрывает продукты не из-за провала, а ради архитектурной миграции.
Присмотритесь внимательно, это не «натягивание совы», а устойчивая закономерность жизненного цикла технологических систем.
«Google не умеет делать нормально, не уммеет в стабильность».
Что умеет и не умеет Google тема дискусионная.. Я убежден что Google остаётся примером компании, у которой рефакторинг и саморазрушение это часть ДНК. Уничтожение Google Reader, миграции GCP сервисов, перезапуск API, переход к IaaS>SaaS это не “некомпетентность”, а следствие ориентации на эволюцию.
Возможно, конкретно вам неудобно или не понятно, но стратегически весьма оправдано.
«Ну покажите мне компанию с институтами, для начала =) ».
Видимо воспрос терминалогии и личного опыта. Я использую этот термин не в академическом смысле, а как описание «устойчивых организационных механизмов»: обучение, ревью-культура, архитектурные комитеты, продуктовое управление. Всё это формы внутренних институтов, которые регулируют поведение и управляет развитием.
Разумеется я допускаю что мой и ваш опыт работы и список компаний могут очень сильно отличаться.
«Про roadmap устаревания убивать надо».
Не согласен с вами. За это нужно вознаграждать. Многие зрелые компании уже так делают. Например, AWS имеет публичный deprecation policy и EOL процессы. Это нормальная инженерная зрелость: признание, что продукт живёт в ограниченном временном окне, и что для его устойчивости нужно планировать не только рост, но и замещение.
«Продукты умирают, потому что кто-то сделал лучше».
Разумеется я с вами согласен, но этого объяснения недостаточно. Часто «лучше» становится возможным именно потому, что старый игрок застрял в инерции собственной архитектуры или процессов (ну или старые разработчики запугали коллег убийством за подобные изменения).
В контексте продуктового управления основная мысль простая: если команда или компания перестала заниматься созидательным разрушением, то есть осознанно пересматривать, заменять и обновлять, она уже начала проигрывать.
Конкуренты обязательно придут и сделают “лучше”, но только потому, что не боятся разрушить своё вчерашнее решение ради будущего.
Спасибо за внимательность! Вы абсолютно правы в том, что премия по экономике формально не была учреждена самим Альфредом Нобелем она основана Банком Швеции в 1968 году «в память об Альфреде Нобеле».
Тем не менее, официальный сайтhttps://www.nobelprize.org/all-nobel-prizes-2025/ прямо относит эту награду к числу Nobel Prizes, перечисляя её в общем списке вместе с премиями по физике, химии и другим направлениям.
Поэтому использование выражения «Нобелевская премия по экономике» — это не ошибка, а устоявшаяся практика, отражённая в официальных материалах самой Нобелевской организации.
Спасибо за вопрос. Да, схема с чистым L3 и /32 или /31 (для IPv4) концептуально можно реализовать в любой сети. И в кампусной сети, и в сети провайдера, но с оговорками. А зачем?
Для облака, VМ, серверных ферм — мне понятна ценность; для массовых клиентских устройств в кампусе, может быть менее практично. Хотя, возможно, я просто не знаю какую проблему вы хотите решить.
Спасибо за инетрес к статье! Если говорить про foreign keys и views, чаще всего всё будет работать, но лучше перед использованием проверить зависимости (чтото типа SELECT * FROM pg_depend WHERE refobjid = 'your_table'::regclass;) Триггеры переносятся, но я бы рекомендовал проверить их после репака.
Насчет шардирвоания. Увы я не эксперт. Прошу прощения, не подскажу.
Насколько я знаю проблема с ограничениями целостности с отложенной проверкой в pgrepack всё ещё актуальна, и её нужно учитывать. Это обсуждалось и в официальном трекере pg_repack и не закрыто как решённое. Проблема затрагивает достаточно специфичные сценарии, но может быть критичной. Можно также рассмотреть pg_squeeze как альтернативу, хотя он тоже не всегда корректно работает с отоложенными проверками.
Спасибо большое за ваш комментарий, но я явно отразил этот момент с диском в разделе "Ограничения и Грабли". Ну и вы абсолютно правы - магии не бывает. Разные инстурменты работают с разными нюансами и ограничениями. Нужно правильно выбирать их под свои задачи.
Спасибо за валидный комментарий. Вы правы. Судя по всему в мае 2024 года в pg_vector действительно появилась поддержка HNSW. И если я правильно понял только для последних версий PG (16 и 17). Еще раз спасибо, я отредактирую статью по следам нашей дискусии.
Спасибо за комментарий, согласен с вашим мнением. Поэтому пишу однозначно что лично я считаю что для реально большого и требовательного проекта можно посмотреть другие инструменты и предлогаю рейтинг.
Спасибо за комментарий — отличный технический вопрос. Но у меня немного другое отношение к этой теме. Да, временные таблицы в PostgreSQL могут дать снижение производительности в определенных ситуациях. Но просто потому что устроены они иначе, чем в MS SQL.
Они создаются на уровне сессии, и не подпадают под autovacuum, и при больших объёмах без явного ANALYZE могут давать неоптимальные планы выполнения. Это особенно заметно при сложных JOIN или GROUP BY о чем действительно очень подробно и по делу написано в представленной вами статье.
PostgreSQL это не MS SQL. Поэтому подходы в лоб типа: "Просто возьми и сделай импортозамещение!" может дать не самый оптимальный результат. Нужно глубже разбираться с инструментами из которых мы строим приложение. И PostgreSQL очень крутой пример.
Спасибо за такой развернутый и крутой комментарий! А еще за интерес к статье. Позволил себе дополнить первый раздел по следам описанных вами идей. Благодарю!
Спасибо за интерес к статье и столь содержательные замечания.
Согласен,
pg_relation_size(...) / 8192не является строгим доказательством того, что таблица физически состоит из страниц. Использовал лишь как удобную демонстрацию того, что объем данных кратен размеру страницы (8 KB по умолчанию). Корректнее будет уточнить, что таблицы PostgreSQL действительно состоят из страниц фиксированного размера, и это подтверждается документацией и внутренней организацией heap-файлов, а приведенный запрос иллюстрация, а не proof. С вашего разрешения я немного скорректирую формулировку в статье по следам вашего комментария.Да, теримн может ввести в заблуждение. Точнее будет сказать:
ctidидентификатор местоположения tuple внутри heap-файла, который включает(block_number, offset_in_page).Это не абсолютный смещённый байтовый адрес, а координаты внутри структуры heap. Благодаря этму PostgreSQL может найти конкретный tuple без индексации, но сам по себе
ctidне указывает положение в виде числа байт. Согласен, что термин стоило уточнить, поправлю.3. PostgreSQL испльзует механизм TOAST (The Oversized-Attribute Storage Technique). Если строка превышает лимит содержание просто выносятся во внешнее TOAST-хранилище, а в tuple остаётся указатель. Поэтому одна tuple всегда помещается в страницу, а большие значения «разамзываются» по TOAST-страницам. Подробнее можно посмотреть в первоисточнике https://www.postgresql.org/docs/current/storage-toast.htm
4. нет никакой карты "просто страниц" и в ней нет необходимости. Таблица просто хранится в виде линейного файла, состоящего из блоков по 8 КБ внутри heap.Номер страницы это её положение внутри файла. Для более глубокого разбора тоже придется обращаться к первоисточнику https://www.postgresql.org/docs/current/storage-file-layout.html
5. Тут вы верно поняли про FSM и VM они не яаляются частью реализации MVCC, состяния легко и просто перезаписываются без версионирования и это ожидаемое поведение продукта. Идея в том, что они просто подсказки для оптимизации запросов, а не критически важный источник истины. В худшем случае PostgreSQL просто сделает лишний IO и перексанирует страницы.
Спасибо за подробный комментарий. Попробую уточнить, в чём, на мой взгляд, произошло недопонимание.
Разумеется, идея не нова от Шумпетера и Клейтона Кристенсена до Мокира и Талеба её рассматривали в разных контекстах. Но речь не о философской максиме, а о прикладном управленческом паттерне.
Компании действительно вынуждены «разрушать» свои старые решения — не в метафизическом, а в инженерном смысле. Примеры есть у всех крупных игроков: Amazon заменил monolith S3 control plane на микросервисы, Netflix несколько раз переписывал систему рекомендаций, а Microsoft закрывает продукты не из-за провала, а ради архитектурной миграции.
Присмотритесь внимательно, это не «натягивание совы», а устойчивая закономерность жизненного цикла технологических систем.
Что умеет и не умеет Google тема дискусионная.. Я убежден что Google остаётся примером компании, у которой рефакторинг и саморазрушение это часть ДНК. Уничтожение Google Reader, миграции GCP сервисов, перезапуск API, переход к IaaS>SaaS это не “некомпетентность”, а следствие ориентации на эволюцию.
Возможно, конкретно вам неудобно или не понятно, но стратегически весьма оправдано.
Видимо воспрос терминалогии и личного опыта. Я использую этот термин не в академическом смысле, а как описание «устойчивых организационных механизмов»: обучение, ревью-культура, архитектурные комитеты, продуктовое управление. Всё это формы внутренних институтов, которые регулируют поведение и управляет развитием.
Разумеется я допускаю что мой и ваш опыт работы и список компаний могут очень сильно отличаться.
Не согласен с вами. За это нужно вознаграждать. Многие зрелые компании уже так делают. Например, AWS имеет публичный deprecation policy и EOL процессы. Это нормальная инженерная зрелость: признание, что продукт живёт в ограниченном временном окне, и что для его устойчивости нужно планировать не только рост, но и замещение.
Разумеется я с вами согласен, но этого объяснения недостаточно. Часто «лучше» становится возможным именно потому, что старый игрок застрял в инерции собственной архитектуры или процессов (ну или старые разработчики запугали коллег убийством за подобные изменения).
В контексте продуктового управления основная мысль простая: если команда или компания перестала заниматься созидательным разрушением, то есть осознанно пересматривать, заменять и обновлять, она уже начала проигрывать.
Конкуренты обязательно придут и сделают “лучше”, но только потому, что не боятся разрушить своё вчерашнее решение ради будущего.
Спасибо за внимательность! Вы абсолютно правы в том, что премия по экономике формально не была учреждена самим Альфредом Нобелем она основана Банком Швеции в 1968 году «в память об Альфреде Нобеле».
Тем не менее, официальный сайт https://www.nobelprize.org/all-nobel-prizes-2025/ прямо относит эту награду к числу Nobel Prizes, перечисляя её в общем списке вместе с премиями по физике, химии и другим направлениям.
Поэтому использование выражения «Нобелевская премия по экономике» — это не ошибка, а устоявшаяся практика, отражённая в официальных материалах самой Нобелевской организации.
Спасибо за интерес к статье!
Спасибо за интерес к статье!
Спасибо за вопрос. Да, схема с чистым L3 и /32 или /31 (для IPv4) концептуально можно реализовать в любой сети. И в кампусной сети, и в сети провайдера, но с оговорками. А зачем?
Для облака, VМ, серверных ферм — мне понятна ценность; для массовых клиентских устройств в кампусе, может быть менее практично. Хотя, возможно, я просто не знаю какую проблему вы хотите решить.
Спасибо за инетрес к статье!
Если говорить про foreign keys и views, чаще всего всё будет работать, но лучше перед использованием проверить зависимости (чтото типа SELECT * FROM pg_depend WHERE refobjid = 'your_table'::regclass;)
Триггеры переносятся, но я бы рекомендовал проверить их после репака.
Насчет шардирвоания. Увы я не эксперт. Прошу прощения, не подскажу.
Насколько я знаю проблема с ограничениями целостности с отложенной проверкой в pgrepack всё ещё актуальна, и её нужно учитывать. Это обсуждалось и в официальном трекере pg_repack и не закрыто как решённое. Проблема затрагивает достаточно специфичные сценарии, но может быть критичной. Можно также рассмотреть pg_squeeze как альтернативу, хотя он тоже не всегда корректно работает с отоложенными проверками.
Спасибо большое за ваш комментарий, но я явно отразил этот момент с диском в разделе "Ограничения и Грабли".
Ну и вы абсолютно правы - магии не бывает. Разные инстурменты работают с разными нюансами и ограничениями. Нужно правильно выбирать их под свои задачи.
Спасибо за столь развернутый и подробный комментарий. Позволю себе отредактироваить и отразить подсвеченные вами моменты в статье.
Спасибо за валидный комментарий. Вы правы. Судя по всему в мае 2024 года в pg_vector действительно появилась поддержка HNSW. И если я правильно понял только для последних версий PG (16 и 17). Еще раз спасибо, я отредактирую статью по следам нашей дискусии.
Спасибо за комментарий, согласен с вашим мнением. Поэтому пишу однозначно что лично я считаю что для реально большого и требовательного проекта можно посмотреть другие инструменты и предлогаю рейтинг.
Благодарю за комментарий, буду продолжать эту тему дальше, подписывайтесь.
Спасибо за интересную статью, про крутой инструмент!
Спасибо за интерес к статье! Спасибо что напомнили этот мем, улыбнуло. Легенда говорил (а может и не говорил) 640кб должно хватить всем!
Хорошее замечание, согласен с вами. Есть сборки для pg для 1С. В том числе в качестве готовой услуги в нашем облаке https://selectel.ru/services/cloud/managed-databases/postgresql-1c/
Спасибо за интерес к статье!
Спасибо за комментарий — отличный технический вопрос. Но у меня немного другое отношение к этой теме. Да, временные таблицы в PostgreSQL могут дать снижение производительности в определенных ситуациях. Но просто потому что устроены они иначе, чем в MS SQL.
Они создаются на уровне сессии, и не подпадают под
autovacuum, и при больших объёмах без явногоANALYZEмогут давать неоптимальные планы выполнения. Это особенно заметно при сложныхJOINилиGROUP BYо чем действительно очень подробно и по делу написано в представленной вами статье.PostgreSQL это не MS SQL. Поэтому подходы в лоб типа: "Просто возьми и сделай импортозамещение!" может дать не самый оптимальный результат. Нужно глубже разбираться с инструментами из которых мы строим приложение. И PostgreSQL очень крутой пример.
Спасибо за такой развернутый и крутой комментарий! А еще за интерес к статье. Позволил себе дополнить первый раздел по следам описанных вами идей. Благодарю!
Валидное дополнение, спасибо! Отражу в разделе про статистику. Благодарю!