Вообщем ребят, проблема не в fork, потому что fork происходит от супервизора с минимумом памяти, проблема в LoadCriticalIndex и кучей других кэшей которые бакенд загружает при старте.
популярное заблуждение, посмотрите на популярность pgbouncer — это костыль именно для решения проблемы fork и вымывания набраного бакендом кэша (например дескрипторы открытых файлов ), но pgbouncer не решает проблемы полностью, например приходиться отказываться от prepared-statement
В реальной жизни — да, из-за особенности версионника. Но вообще есть костылики в виде pg_repack и регламентное временя. Второй пример — это поиск по временному диапазону в append-only таблице.
Нарисую пример при котором важен кластерный индекс: допустим у вас таблица Users, в нем есть поле LastLoginDate. Пользователей у которых LastLoginDate меньше месяца назад — всего 10%, поэтому они разбросаны по таблице. но ДБ не загружает конкретные строки, она загружает данные блоками, тоесть вам понадобилась одна строчка из блока — а загрузиться весь блок, и в нем 90% не нужных вам пользователей. При помощи кластера вы можете отстортировать таких пользователей по LastLoginDate и тогда ДБ будет работать эффективнее.
Я уже писал об этом, для стейджинга/прода вы можете использовать пакет вашего администратора/дистрибутива/сообщества. А у себя на ноутбуке — да, можно и нужно собрать из исходников, хотя бы для того, чтобы понять что это и как оно работает, если вы его собираетесь использовать в продуктиве.
Потому что я администратор, я собрал не одну сотню пакетов под разные дистрибутивы, и не рекомендую превращать рабочую машину в мусор. Cоветую поддержку повесить все-таки на плечи администратора или дистрибутива. А администратору контролировать права на сервере :)
Но перед тем, как это окажется на вашем сервер, вы должны попробовать локально, как — описано в статье.
Александр — мой руководитель, и ему под силу написать в ядро патчи, которые необходимы. Но если это не примут в ядро (а хинтов нет в ядре), то поддерживать компанией пачку таких расширений на голом энтузиазме невозможно.
вы абсолютно правы, надо сделать функции под типичные запросы, другого способа подсказать планеру нет (как и хинтов). скорее всего сообщество не пойдет на подобные "хинты", а реализовать подобное без поддержки ядра не возможно.
github — это вообще не явление, github — это сторонняя компания, мне кажется это одна из причин по которой не ведется разработка таких проектов как linux/kernel, freebsd или PostgreSQL на github.
PostgreSQL может авторизовать пользователя не только по паролю, но и по факту того что процесс запущен от пользователя, который совпадает с пользователем базы: http://postgrespro.ru/doc/auth-methods.html#AUTH-IDENT.
SuperUser'ов (аналог root в mysql) в PostgreSQL может быть несколько, по умолчанию это postgres.
Под другим пользователем — psql -U otheruser, советую почитать: http://postgrespro.ru/doc/client-authentication.html
человек спрашивал про интерфейс жмяк-жмяк, а вы его в другие дебри заташили :)
смысл в том, что то, о чем просит человек — теоритическая не решаемая задача (нужно снять логический дамп с --no-owner, восстанавливать логический дамп под owner'ом базы, но есть проблемы с extensions)
к сожалению вы выбрали дистрибутив, который требует участия администратора в инициализации кластера: https://wiki.postgresql.org/wiki/YUM_Installation
на debian-like после инсталяции будет запущен работоспособный инстанс (хотя и не утверждаю что это правильнее)
Очень доступно и круто!
Вообщем ребят, проблема не в fork, потому что fork происходит от супервизора с минимумом памяти, проблема в LoadCriticalIndex и кучей других кэшей которые бакенд загружает при старте.
популярное заблуждение, посмотрите на популярность pgbouncer — это костыль именно для решения проблемы fork и вымывания набраного бакендом кэша (например дескрипторы открытых файлов ), но pgbouncer не решает проблемы полностью, например приходиться отказываться от prepared-statement
Денег полковника Захарченко хватило на аренду модели с 1080 ядер ровно на 140 лет.
В реальной жизни — да, из-за особенности версионника. Но вообще есть костылики в виде pg_repack и регламентное временя. Второй пример — это поиск по временному диапазону в append-only таблице.
Нарисую пример при котором важен кластерный индекс: допустим у вас таблица Users, в нем есть поле LastLoginDate. Пользователей у которых LastLoginDate меньше месяца назад — всего 10%, поэтому они разбросаны по таблице. но ДБ не загружает конкретные строки, она загружает данные блоками, тоесть вам понадобилась одна строчка из блока — а загрузиться весь блок, и в нем 90% не нужных вам пользователей. При помощи кластера вы можете отстортировать таких пользователей по LastLoginDate и тогда ДБ будет работать эффективнее.
Я уже писал об этом, для стейджинга/прода вы можете использовать пакет вашего администратора/дистрибутива/сообщества. А у себя на ноутбуке — да, можно и нужно собрать из исходников, хотя бы для того, чтобы понять что это и как оно работает, если вы его собираетесь использовать в продуктиве.
Потому что я администратор, я собрал не одну сотню пакетов под разные дистрибутивы, и не рекомендую превращать рабочую машину в мусор. Cоветую поддержку повесить все-таки на плечи администратора или дистрибутива. А администратору контролировать права на сервере :)
Но перед тем, как это окажется на вашем сервер, вы должны попробовать локально, как — описано в статье.
Александр — мой руководитель, и ему под силу написать в ядро патчи, которые необходимы. Но если это не примут в ядро (а хинтов нет в ядре), то поддерживать компанией пачку таких расширений на голом энтузиазме невозможно.
вы абсолютно правы, надо сделать функции под типичные запросы, другого способа подсказать планеру нет (как и хинтов). скорее всего сообщество не пойдет на подобные "хинты", а реализовать подобное без поддержки ядра не возможно.
Это никак не предусмотренно. Вы можете изменить свой запрос для удаленного сервера, чтобы он эффективнее выполнялся.
Это известная проблема, что PostgreSQL прикидывается, что не видит соседние бд, но при этом кластер использует общий xid, shared buffers и тд и тп.
у нас еще 3 пользователя fedora, в том числе был и майнтейнер fedora, а сейчас штатный сотрудник Red Hat.
Спасибо, Алексей, исправил
github — это вообще не явление, github — это сторонняя компания, мне кажется это одна из причин по которой не ведется разработка таких проектов как linux/kernel, freebsd или PostgreSQL на github.
PostgreSQL может авторизовать пользователя не только по паролю, но и по факту того что процесс запущен от пользователя, который совпадает с пользователем базы: http://postgrespro.ru/doc/auth-methods.html#AUTH-IDENT.
SuperUser'ов (аналог root в mysql) в PostgreSQL может быть несколько, по умолчанию это postgres.
Под другим пользователем — psql -U otheruser, советую почитать: http://postgrespro.ru/doc/client-authentication.html
человек спрашивал про интерфейс жмяк-жмяк, а вы его в другие дебри заташили :)
смысл в том, что то, о чем просит человек — теоритическая не решаемая задача (нужно снять логический дамп с --no-owner, восстанавливать логический дамп под owner'ом базы, но есть проблемы с extensions)
service reload <name>кластер например можно инициализировать (а потом это нельзя уже изменить) как с cheksums так и без, конечно у человека должен быть выбор
к сожалению вы выбрали дистрибутив, который требует участия администратора в инициализации кластера: https://wiki.postgresql.org/wiki/YUM_Installation
на debian-like после инсталяции будет запущен работоспособный инстанс (хотя и не утверждаю что это правильнее)