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

@Komzpa

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

Так блин, смысл не в том, чтобы скрывать, а чтобы эти твари не лезли

они же уроды шерстят чат и ссылки на другие чаты ищут небось

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

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

а когда начнут? будем ждать?

от ботов в любом случае не избавиться до появления ИИ)

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

такая, что вот уже в 3 чатах их вижу, в одном взяли терминатора, в другом автобанилка с голосовалкой, а тут вот пока нихрена

они не должны тут сидеть и иметь возможность отрывать ссылки на другие чаты

в этом суть. чтоб у этих уродов база ссылок не росла

такая, что вот уже в 3 чатах их вижу, в одном взяли терминатора, в другом автобанилка с голосовалкой, а тут вот пока нихрена

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

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

сам же подтвердил, что поиск ненужен) я тоже не поиском например

я думаю саппорт телеги пинать лучше

Подскажите, пожалуйста. Есть таблица, в которую пишется и удаляется много записей (транзакционная очередь), сама таблица почти пустая, но её toast стал 300 ГБ. Может ли это место освободить vacuum full? Если может, то он заблокирует таблицу на длительное время? Если так, то может, например, pg_repack помочь освободить это место не блокируя таблицу надолго?

вакуум фулл освободит

т.к. по сути создаст новую таблицу

но вам нужно на будущее разобраться с настройками автовакуума

Vacuum full да, все поперелочит и освободит место. Лучше pg repack, он отдельно вытащит актуальные данные в другую таблицу, и перименует её, взяв короткий лок

выставить более агрессивные

Vacuum full да, все поперелочит и освободит место. Лучше pg repack, он отдельно вытащит актуальные данные в другую таблицу, и перименует её, взяв короткий лок

+

Есть, вот такой юзкейс: несколько параллельных транзакций которые потенциально модифицируют одно и то же, но при этом гарантируется что только одна применится. Можно ли как-то настроить постгрес чтобы эти транзакции не лочили ничего?

нет

Но я не уверен

Так что ты поищи обязательно

Добрый день! использую базу данных на дроплете digital ocean база на ssd, 64 Гб ОЗУ, 16 ядер в пик нагрузки база упирается в IOPS (по мониторингу хостинга утилизация по IOPS до 160%), при этом память используется на 2-3 ГБ из 64 возможных сама база занимает 10 Гб Подскажите, пожалуста, какие параметры необходимы для более эффективного использхования памяти и настройк IO диска спасибо!

Добрый день! использую базу данных на дроплете digital ocean база на ssd, 64 Гб ОЗУ, 16 ядер в пик нагрузки база упирается в IOPS (по мониторингу хостинга утилизация по IOPS до 160%), при этом память используется на 2-3 ГБ из 64 возможных сама база занимает 10 Гб Подскажите, пожалуста, какие параметры необходимы для более эффективного использхования памяти и настройк IO диска спасибо!

pgtune)

Добрый день! использую базу данных на дроплете digital ocean база на ssd, 64 Гб ОЗУ, 16 ядер в пик нагрузки база упирается в IOPS (по мониторингу хостинга утилизация по IOPS до 160%), при этом память используется на 2-3 ГБ из 64 возможных сама база занимает 10 Гб Подскажите, пожалуста, какие параметры необходимы для более эффективного использхования памяти и настройк IO диска спасибо!

http://pgtune.leopard.in.ua

http://pgtune.leopard.in.ua

спасибо) я как раз использовал значения этого калькулятора и никаких изменений не увидел

а что такое 160% IOPS? ведь иопсы - это абсолютное значение

а насколько важна эта база?

Есть, вот такой юзкейс: несколько параллельных транзакций которые потенциально модифицируют одно и то же, но при этом гарантируется что только одна применится. Можно ли как-то настроить постгрес чтобы эти транзакции не лочили ничего?

Нет, UPDATE всегда использует lock-и. А что за требование "чтобы не лочили ничего"? Т.е. зачем оно?

Добрый день! использую базу данных на дроплете digital ocean база на ssd, 64 Гб ОЗУ, 16 ядер в пик нагрузки база упирается в IOPS (по мониторингу хостинга утилизация по IOPS до 160%), при этом память используется на 2-3 ГБ из 64 возможных сама база занимает 10 Гб Подскажите, пожалуста, какие параметры необходимы для более эффективного использхования памяти и настройк IO диска спасибо!

А какие настройки-то вам выдал pgtune?

Нет, UPDATE всегда использует lock-и. А что за требование "чтобы не лочили ничего"? Т.е. зачем оно?

Чтобы параллельно выполнять несколько транзакций

Чтобы параллельно выполнять несколько транзакций

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

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

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

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

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

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

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

Если блочатся, значит локи-то почти наверняка нужны (иначе у вас получаются lost updates... это как минимум). > консенсус для распределенной системы А подробнее?

Если блочатся, значит локи-то почти наверняка нужны (иначе у вас получаются lost updates... это как минимум). > консенсус для распределенной системы А подробнее?

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

Соответственно конфликтов и проблем быть не должно

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

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

Ну у тебя каша в голове, всё смешано. Тебе локи тут не будут мешать вообще (а будут помогать). Так что думай глубже.

Ну у тебя каша в голове, всё смешано. Тебе локи тут не будут мешать вообще (а будут помогать). Так что думай глубже.

Хмм, как раз таки они мешают, так как если к примеру идёт update на одну и ту же строчку, даже при repeatable read идёт блокировка одного из апдейтов, что не нужно, так как только один из них в итоге закоммититься

Ну ещё раз, думай глубже...

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

Всё равно непонятно... По какому принципу они применяются? "Кто первый встал, того и тапки?". ;)

Всё равно непонятно... По какому принципу они применяются? "Кто первый встал, того и тапки?". ;)

Остальные пиры голосуют и применяется та за которую большинство проголосовало. Грубо говоря каждая транзакция собирает голоса и применяется та которая первая собирает определенное кол-во

Остальные пиры голосуют и применяется та за которую большинство проголосовало. Грубо говоря каждая транзакция собирает голоса и применяется та которая первая собирает определенное кол-во

Я бы не сказал, что становится понятнее. :( А голосуют они как? "Вне" PostgreSQL или всё-таки "внутри" базы? Откуда они знают, за какую голосовать (результат её, кстати, ведь ещё не может быть известен)? Зачем вообще что-то применяется до завершения голосования?

Такс, сейчас попробую пояснить, заранее извиняюсь за косноязычие. Есть пиры, это грубо говоря сервисы которые применяют команды пользователя. Эти команды в каком-то месте собираются, и генерируется транзакция. Она рассылается всем пирам. Сами команды это грубо говоря изменения состояния. Состояние хранится в постгресе. Как только пир получает транзакцию, ему ее нужно провалидировать. Валидация заключается в применении транзакции к базе. Если транзакция успешно применилась - она валидна и пир за нее голосует. Как только какая-либо из транзакций собрала определенное количество голосов, ее можно закоммитить в базу. Это считается одним раундом. В следующем раунде все повторяется. Так вот, есть желание чтобы в одном раунде было несколько транзакций, которые одновременно применяются и за них идут голоса. В итоге закоммититься должна только одна, которая быстрее собрала голоса. Проблема в том что несколько транзакций в одном раунде могут менять одно и тоже, что вызывает блокировку одной из них. Хочется как-то избавиться от этой блокировки.

Описал, как смог, если что непонятно спрашивайте

Ах да, под применением подразумевается исполнение всех квери, без коммита в конце

Конкретно сам коммит идёт после голосования

о, это же типа блокчейн получается?

сорри за офтоп

Он и есть, только консенсус не proof of smth, а голосование

Он и есть, только консенсус не proof of smth, а голосование

proof of popularity? :)

Такс, сейчас попробую пояснить, заранее извиняюсь за косноязычие. Есть пиры, это грубо говоря сервисы которые применяют команды пользователя. Эти команды в каком-то месте собираются, и генерируется транзакция. Она рассылается всем пирам. Сами команды это грубо говоря изменения состояния. Состояние хранится в постгресе. Как только пир получает транзакцию, ему ее нужно провалидировать. Валидация заключается в применении транзакции к базе. Если транзакция успешно применилась - она валидна и пир за нее голосует. Как только какая-либо из транзакций собрала определенное количество голосов, ее можно закоммитить в базу. Это считается одним раундом. В следующем раунде все повторяется. Так вот, есть желание чтобы в одном раунде было несколько транзакций, которые одновременно применяются и за них идут голоса. В итоге закоммититься должна только одна, которая быстрее собрала голоса. Проблема в том что несколько транзакций в одном раунде могут менять одно и тоже, что вызывает блокировку одной из них. Хочется как-то избавиться от этой блокировки.

> Если транзакция успешно применилась - она валидна и пир за нее голосует. Вы в курсе, что до COMMIT-а это (теоретически) узнать нельзя? Да, я знаю, что многие на практике делают вид, что это не так... но в сложных случаях (вроде вашего), это должно быть важно.

Ну поскольку голосование идёт раундами, то я точно знаю что во время раунда состояние не изменится

Поэтому тут в частном случае наверное могу гарантировать

Поэтому тут в частном случае наверное могу гарантировать

Технически — не с MVCC (и с не 2PL, конечно). Тут, похоже, нужно было бы иметь несколько обновлённых версий той же записи / потенциальных "историй". Вообще, то, что вы описываете, напоминает вариант optimitstic concurrency control... и из широко используемых СУБД его не поддерживает почти никто. Может быть, у вас получится его как-то имитировать?

Технически — не с MVCC (и с не 2PL, конечно). Тут, похоже, нужно было бы иметь несколько обновлённых версий той же записи / потенциальных "историй". Вообще, то, что вы описываете, напоминает вариант optimitstic concurrency control... и из широко используемых СУБД его не поддерживает почти никто. Может быть, у вас получится его как-то имитировать?

Да, про несколько я записей я примерно об этом и думал. То есть с технической части это понятно как делается, просто раз уже используется постгрес, хотелось узнать можно ли его подогнать под это дело. Видимо просто так нет, спасибо, будем думать.

Добрый день! использую базу данных на дроплете digital ocean база на ssd, 64 Гб ОЗУ, 16 ядер в пик нагрузки база упирается в IOPS (по мониторингу хостинга утилизация по IOPS до 160%), при этом память используется на 2-3 ГБ из 64 возможных сама база занимает 10 Гб Подскажите, пожалуста, какие параметры необходимы для более эффективного использхования памяти и настройк IO диска спасибо!

Например, *выключить синхронный commit (ценой потери последних транзакций) https://postgrespro.ru/docs/postgrespro/10/wal-async-commit *увеличить shared_buffers, чтобы база целиком влезала +huge_pages (разд. 19.4.5. документации) https://postgrespro.ru/docs/postgrespro/10/kernel-resources А сколько в итоге получается IOPS ?

Например, *выключить синхронный commit (ценой потери последних транзакций) https://postgrespro.ru/docs/postgrespro/10/wal-async-commit *увеличить shared_buffers, чтобы база целиком влезала +huge_pages (разд. 19.4.5. документации) https://postgrespro.ru/docs/postgrespro/10/kernel-resources А сколько в итоге получается IOPS ?

800 IOPS выдает дроплет чистыми

Да, про несколько я записей я примерно об этом и думал. То есть с технической части это понятно как делается, просто раз уже используется постгрес, хотелось узнать можно ли его подогнать под это дело. Видимо просто так нет, спасибо, будем думать.

А насколько "тяжелые" там изменения предполагаются? Может быть, каждую транзакцию можно организовать в виде "сделать копию данных, применить изменения к копии, подменить копией источник"?

А насколько "тяжелые" там изменения предполагаются? Может быть, каждую транзакцию можно организовать в виде "сделать копию данных, применить изменения к копии, подменить копией источник"?

Потенциально несколько сотен инсертов/апдейтов на транзакцию

Добрый день! использую базу данных на дроплете digital ocean база на ssd, 64 Гб ОЗУ, 16 ядер в пик нагрузки база упирается в IOPS (по мониторингу хостинга утилизация по IOPS до 160%), при этом память используется на 2-3 ГБ из 64 возможных сама база занимает 10 Гб Подскажите, пожалуста, какие параметры необходимы для более эффективного использхования памяти и настройк IO диска спасибо!

Мне вот этот больше, чем леопардовский pgtune, нравится: http://pgconfigurator.cybertec.at/

Мне вот этот больше, чем леопардовский pgtune, нравится: http://pgconfigurator.cybertec.at/

спасибо!

ERROR: S client not available

Ребятки, подскажите по этим таблицам: CREATE TABLE feature ( id BIGSERIAL PRIMARY KEY, code TEXT NOT NULL, name TEXT NOT NULL, description TEXT NOT NULL ); CREATE INDEX feature_code_idx ON feature USING hash(code); CREATE TABLE feature_data ( feature_id BIGINT PRIMARY KEY REFERENCES feature(id), values JSONB NOT NULL ); Вопросов несколько: 1. Хэш индекс ок вешать на code? Сортировок не будет по этому полю, будет только прямая выборка WHERE code = $1 2. Имеет ли смысл делать PRIMARY KEY REFERENCES? Или убрать с него PRIMARY KEY, и повесить хеш индекс, он будет в джойне участвовать? 3. Или может вообще слить две таблицы в одну?

Речь идет о таблице с характеристиками товаров, в значение values будут попадать все значение для определенной характеристики.

1. хеш не надо, btree лучше

2-3. primary key references - это 1:1, то есть по сути одна таблица. такое стоит делать только если тебе мешают слить в одну таблицу это всё какие-то другие характеристики базы.

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

https://www.postgresql.org/docs/9.6/static/indexes-types.html

Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash if there were unwritten changes. Also, changes to hash indexes are not replicated over streaming or file-based replication after the initial base backup, so they give wrong answers to queries that subsequently use them. For these reasons, hash index use is presently discouraged.

их надо использовать никогда

у меня 10, а там такой таблички нет)

это единственная причина?

я помню, что по бенчмаркам они то на то с btree, а умеют меньше

хеш имеет смысл строить (если у вас версия 10+) по полям с уникальными значениями, потому что в этом случае они - меньше чем btree займут места на диске - быстрее доступ

если значения не особо уникальные, то хеш лучше не использовать

и мы пока еще не до конца для себя выяснили его влияние на операции изменения данных

Речь идет о таблице с характеристиками товаров, в значение values будут попадать все значение для определенной характеристики.

А вы уверены, что вам действительно нужен (фактически) EAV? Впрочем, если у этих "характеристик" ценность не высока (т.е. последствия того, что там будет "мусор"), да и в запросах они не сильно участвуют, оно и "сойдёт", конечно. ;)

я помню, что по бенчмаркам они то на то с btree, а умеют меньше

по бенчмаркам hash показал себя хуже, чем btree

хеш имеет смысл строить (если у вас версия 10+) по полям с уникальными значениями, потому что в этом случае они - меньше чем btree займут места на диске - быстрее доступ

Вы это на реальных данных видели? Я вот видел только наоборот, пока что. :(

Да, использовали в OLAP базе и получили несколько часов профит на аггрегациях

http://rhaas.blogspot.com/2017/09/postgresqls-hash-indexes-are-now-cool.html начали со статьи этой изучение

из минусов пока есть подозрения, что hash замедляет bulk-вставки по сравнению с btree, но на разных тестах выходило по разному

так как тестирование было не в вакууме, пока никак не подтвердили это ?

Да, использовали в OLAP базе и получили несколько часов профит на аггрегациях

То есть, в каком именно случае? Именно для SELECT-ов из неё? Какого, примерно, вида?

Подскажите, плиз, кто-то реализовывал партиционирование по служебному полю (дата последнего изменения)? На сколько это оправдано? Какие есть минусы? Лучше ли делать это по бизнесовым датам (которые +- не кочуют по партициям)? Допустим, версия PostgreSQL 11 Основная идея со служебным полем, чтобы в некоторых партициях были самые запрашиваемые данные, а другие разносить на медленные диски

если значения не особо уникальные, то хеш лучше не использовать

да, code уникальная будет, забыл прописать констрейнт.

То есть, в каком именно случае? Именно для SELECT-ов из неё? Какого, примерно, вида?

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

хеш имеет смысл строить (если у вас версия 10+) по полям с уникальными значениями, потому что в этом случае они - меньше чем btree займут места на диске - быстрее доступ

версия последняя, 10.4

из минусов пока есть подозрения, что hash замедляет bulk-вставки по сравнению с btree, но на разных тестах выходило по разному

Хмм... а какое отношение размера базы к RAM у вас, примерно? Потому что, теоретически, даже обычную вставку hash-index должен "просаживать" так же, как UUID-ы... даже без UUID-ов. ;)

А вы уверены, что вам действительно нужен (фактически) EAV? Впрочем, если у этих "характеристик" ценность не высока (т.е. последствия того, что там будет "мусор"), да и в запросах они не сильно участвуют, оно и "сойдёт", конечно. ;)

А альтенатива какая-то есть?

А альтенатива какая-то есть?

вшить jsonb в таблицу и сделать по ней gist/gin

так я вроде это и сделал, не?

ну кроме индекса

чуть позже его пропишу