а вообще, насколько сложно научить постгрес вставлять в те странички, в которых уже есть похожие значения?

**похожие** в контексте uuid?! нунезнаааю

жирную свинью вы себе с этим типом данных подложили

uuid срач го

**похожие** в контексте uuid?! нунезнаааю

похожие в контексте order by id, ts

в этом контексте хоть text

а вообще, насколько сложно научить постгрес вставлять в те странички, в которых уже есть похожие значения?

Хотите безумную (и скорее всего неработоспособную) идею? Можно нагенерировать пустых записей под ожидаемое количество событий для каждого пользователя в рамках интервала. Так как они будут созданы пачкой, то будут располагаться близко на странице. А потом по мере происхождения событий эти пустые заглушки апдейтить. Но это на правах теории, в практике я не знаю, даст ли это что-то кроме головной боли

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

а без этого - похоже на fillfactor

кажется, что если научить постгрес не писать юзеров с разным id на одну страницу, получится то, что нужно

Хотите безумную (и скорее всего неработоспособную) идею? Можно нагенерировать пустых записей под ожидаемое количество событий для каждого пользователя в рамках интервала. Так как они будут созданы пачкой, то будут располагаться близко на странице. А потом по мере происхождения событий эти пустые заглушки апдейтить. Но это на правах теории, в практике я не знаю, даст ли это что-то кроме головной боли

да нигде не гарантируется размещение на одной странице а помня о том что сейчас мало-мальски серьёзные сервера все на ссд то вообще встаёт в полный рост вопрос и про то же партиционирование

да нигде не гарантируется размещение на одной странице а помня о том что сейчас мало-мальски серьёзные сервера все на ссд то вообще встаёт в полный рост вопрос и про то же партиционирование

апдейт при наличии свободного места в странице как раз более-менее гарантирует

кажется, что если научить постгрес не писать юзеров с разным id на одну страницу, получится то, что нужно

Вряд ли это получится без капитального изменения кода. Ещё же есть внутристраничная очистка. Сейчас постгрес пишет просто в свободное место, а так он должен помнить карту паользователей по страницам

кажется, что если научить постгрес не писать юзеров с разным id на одну страницу, получится то, что нужно

еще раз. при поиске какого-то евента требуется что бы "соседние" оказывались в озу? или я не догоняю всего действа

Вряд ли это получится без капитального изменения кода. Ещё же есть внутристраничная очистка. Сейчас постгрес пишет просто в свободное место, а так он должен помнить карту паользователей по страницам

посмотреть в страницу, если нашёлся пользователь с таким же id - считать страницу полной

где просадка и за счет чего хотите получить выигрыш?

данные на записи пишутся как order by ts, нужно вытаскивать по id=N and ts between, выигрыш за счёт более локального расположения id

А сколь большие поля идут после id и ts? Покрывающий индекс не вариант?

горка float'ов и короткий text

горка float'ов и короткий text

Так может их в jsonb и покрывающий индекс по ts,id и jsonb?

ts, id, float1, float2, float3, ... , text1 не будет аналогичен?

Кроме религиозного ужаса перед индексом по более чем четырём колонкам. Но по идее - одно и то же

а вообще, насколько сложно научить постгрес вставлять в те странички, в которых уже есть похожие значения?

сделать типа кластерного индекса пожоже. ну то есть новый тип хранилища для и пг ну и заодно и новую бд вслед за этим %)

Хотите безумную (и скорее всего неработоспособную) идею? Можно нагенерировать пустых записей под ожидаемое количество событий для каждого пользователя в рамках интервала. Так как они будут созданы пачкой, то будут располагаться близко на странице. А потом по мере происхождения событий эти пустые заглушки апдейтить. Но это на правах теории, в практике я не знаю, даст ли это что-то кроме головной боли

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

советы ведущих собаководов, использовать базу вместо pg

:)

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

А можно поподробнее про скапливание в конце? То есть постгрес статистически чаще выбирает свободные странички с большими адресами?

alter table set tablespace на ходу можно делать?

alter table set tablespace на ходу можно делать?

с pg_repack вроде можно

-s, —tablespace=TBLSPC move repacked tables to a new tablespace -S, —moveidx move repacked indexes to TBLSPC too

хм

спасибо

можно и без pg_repack, но требует ACCESS EXCLUSIVE

он сам лок сделает?

да

можно и без pg_repack, но требует ACCESS EXCLUSIVE

это не online :D

ещё можно NOWAIT в команду добавить

это не online :D

ну да, зависит от нагрузки же

ещё можно NOWAIT в команду добавить

оно же вылетит, если не сможет залочить

получается pg_repack сам делает alter table ?

оно же вылетит, если не сможет залочить

да, это чтобы не ждать под нагрузкой

я лучше подожду пока он лок получит и начнёт переносить

А можно поподробнее про скапливание в конце? То есть постгрес статистически чаще выбирает свободные странички с большими адресами?

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

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

Вообще это ожидаемое поведение в истории, когда автовакуума не хватает ресурсов на почистить. В таком случае да, боль.

patroni при запуске ругается : patroni.exceptions.PostgresConnectionException: "'Too many retry attempts'" шаблон : https://pastebin.com/TM2s244a есть идеи ? Я насколько помню вы используете патрони Игорь

запускаю патрони так : patroni /etc/patroni/postgres0.yml

Вообще это ожидаемое поведение в истории, когда автовакуума не хватает ресурсов на почистить. В таком случае да, боль.

у нас появились некоторые соображения в этом вопросе. Пока мы в PgPro исследования проводим и ведем работу в направлении улучшения данной ситуации. следите за анонсами =)

у нас появились некоторые соображения в этом вопросе. Пока мы в PgPro исследования проводим и ведем работу в направлении улучшения данной ситуации. следите за анонсами =)

А куда подписываться и ставить лайк по конкретно этому вопросу?))

info@postgrespro.ru %)))

patroni при запуске ругается : patroni.exceptions.PostgresConnectionException: "'Too many retry attempts'" шаблон : https://pastebin.com/TM2s244a есть идеи ? Я насколько помню вы используете патрони Игорь

пробел то убери (- createdb) и почему закоментирована namespace

Игорь убрал все равно таже ошибка , даже закоментировал users: admin: password: admin options: -createrole -createdb все равно не завелся, в namespace что записать ?

корень (название директории), куда будут складываться имена кластеров. У тебя похоже postgresql не запускается а не patroni. Смотри логи короче, что как маленький

День добрый. Подскажите какая причина данной ошибки Npgsql.PostgresException: 42883: operator is only a shell: text + character varying

Игорь в моем случае корень будет /etc/patroni/ ? У меня yml там лежит

Игорь в моем случае корень будет /etc/patroni/ ? У меня yml там лежит

корень в etcd

Игорь спасибо,постараюсь больше не беспокоить

Добрый день. Уткнулся в извечную проблему - не могу до конца установить PostgreSQL на Windows 7 32-bit (для учебного проекта). Ошибки - точь-в-точь как здесь: https://stackoverflow.com/questions/30689251/failed-to-load-sql-modules-into-the-database-cluster-during-postgresql-installat Пробовал приведенные в этом треде методы - создать админ-пользователя и установить из-под него - симптомы повторяются. Быть может здесь есть у кого-то надежный метод решения проблемы?

заюзай докер/поставь линукс в виртуальную машину

да, лучше используй докер

Эх... Я надеялся на какие-то более "нативные" методы. Ну... ладно. Буду пытаться дальше.

Докер есть для винды

Постгрес запускается в одну команду

Типа всё запустить или выделенный/"под курсором" запрос.

ERROR: S client not available

я не выделяю ничего, оно само это делает

Допиши ещё один запрос, после ;, и запусти стейтмент может тогда будет нагляднее что оно выделяет.

он ещё и сложные запросы по внутренностям разбирает, очень удобно

дебажишь cte, потом дебажишь всё остальное :)

вангую какой-то кривопуть

Ну собственно путь оказался по type psql такой: /usr/local/pgsql/bin/pgsql

Ребятушки, хелп! Благодаря стараниям нашего тимлида, постоянно килявшего процессы вакуума, счетчик транзакций переполнился. В сингл-моде запустил базу, при запуске выделил 0 гигов памяти вот таким вот образом: postgres --single -D /var/lib/pgsql/9.5/data/ -S 80GB my_fucking_db Но вакуумится чет безумно долго. База весит 350 гигов. Есть ли методы, чтоб ускорить?

если запускать vacuum full, то хотя бы прогресс виден, если просто vacuum, то в стдауте тишина, хотя рекомендуют просто вакуум для скорости вроде как. Постгрес 9.5

350 гиг? А на каком железе?

HDD 2x2Tb, RAID1, 120 GB RAM, Xeon(R) CPU E5-1650 v3 @ 3.50GHz

Там говноархитектура, огромные таблицы, которые все никак не могут партиционировать и мне не дают, приход вакуума в них==пиздец. А тут еще накопилось

Ребятушки, хелп! Благодаря стараниям нашего тимлида, постоянно килявшего процессы вакуума, счетчик транзакций переполнился. В сингл-моде запустил базу, при запуске выделил 0 гигов памяти вот таким вот образом: postgres --single -D /var/lib/pgsql/9.5/data/ -S 80GB my_fucking_db Но вакуумится чет безумно долго. База весит 350 гигов. Есть ли методы, чтоб ускорить?

Может, быстрее будет сделать pg_dump и восстановить из логического дампа?

ох, сомневаюсь

т.е., я сделал все правильно и хитростей тут никаких нет? ну кроме переноса на ссд и прочего

Сколько уже по времени вакуум работает? На таком железе 350 гиг база за пару часов поднялась бы.

HDD 2x2Tb, RAID1, 120 GB RAM, Xeon(R) CPU E5-1650 v3 @ 3.50GHz

1-й рейд. На запись. Способов ускорить нет и не будет. Поди ещё и диски десктопные о 5400 rpm?

часа 4

сколько потоков вакуума запускаете?

синглмод, говорю же

Сколько уже по времени вакуум работает? На таком железе 350 гиг база за пару часов поднялась бы.

Сильно зависит от того, насколько база фрагментирована.

Особенно, если индексов есть и немало.

1-й рейд. На запись. Способов ускорить нет и не будет. Поди ещё и диски десктопные о 5400 rpm?

7200 WD RE 2TB

В любом случае иных вариантов, кроме как сидеть и ждать нет и не будет.

ну можно увеличить maintenance_work_mem например

postgres —single -D /var/lib/pgsql/9.5/data/ -S 80GB my_fucking_db

80 гигов, куда уж увеличивать

это не тот параметр

пардон, точно

это ж work-mem

ща попробую

насколько вижу, больше 10 Гб ставить не рекомендуют https://blog.sentry.io/2015/07/23/transaction-id-wraparound-in-postgres.html