V
Чем не устраивает стандартный list, зачем пытаться запихать данные в БД?
Я там сортировал лист
юзал .pop() .insert() и тд
Size: a a a
2020 May 28
СП
менял позиции итемов
например, поднимал (.insert(0)) item на вершину, или аппендил
например, поднимал (.insert(0)) item на вершину, или аппендил
СП
Чем не устраивает стандартный list, зачем пытаться запихать данные в БД?
Мало юзает РАМ
T
Сложно настраивается? А то нужно HA улучшить.
Если готовы смириться с возможной потерей данных, используйте patroni.
BTW, сами создатели patroni своё детище в проде не используют.
BTW, сами создатели patroni своё детище в проде не используют.
СП
Мало юзает РАМ
Не лоадид весь огромный лист на прогу
T
Все как то сложно у вас.
ну pg_upgrade не длится 40-50 минут
(Через pg_dump/pg_restore уйдет минут 40-50.)
ну pg_upgrade не длится 40-50 минут
(Через pg_dump/pg_restore уйдет минут 40-50.)
В теории, можно, т.к. библиотечные аллокаторы не идеальны.
Касаемо postgres, страницы чётко занимают 2 pages, а память под всё, кроме мимолётных worker-ов, уже выделена.
Касаемо postgres, страницы чётко занимают 2 pages, а память под всё, кроме мимолётных worker-ов, уже выделена.
БЁ
Здравствуйте! Подскажите пожалуйста, поддерживает ли COPY перенос данных из базы в базу одним махом? Две базы на одном сервере
СГ
Борщевик Ёбаный
Здравствуйте! Подскажите пожалуйста, поддерживает ли COPY перенос данных из базы в базу одним махом? Две базы на одном сервере
можете дать определение одного маха?
БЁ
без промежуточных складываний куда-то
V
Борщевик Ёбаный
Здравствуйте! Подскажите пожалуйста, поддерживает ли COPY перенос данных из базы в базу одним махом? Две базы на одном сервере
Я бы через psql и конвейер сделал
СГ
Борщевик Ёбаный
без промежуточных складываний куда-то
pg_dump | psql
СГ
Я бы через psql и конвейер сделал
+
БЁ
благодарю
АФ
У нас несколько таблиц биллинга. 100м записей. Айди в каждой таблице это хэш из 32 символов. Хэши могут повторятся. Уникальной является комбинация нескольких хэшей в одной таблице. Сейчас даже с индексом по такому хэшу ищет долго, а нужно будет по таблице делать аналитику и сложные запросы вроде найти все записи из таблицы 1 где во второй есть отрицательные значения в определенной категории строк
Хэш из 32 символов какого вида? Не 16-ричные символы случайно?
П
Если готовы смириться с возможной потерей данных, используйте patroni.
BTW, сами создатели patroni своё детище в проде не используют.
BTW, сами создатели patroni своё детище в проде не используют.
А если реплика синхронная?
Да и с асинхронной так и не уложу в голове где потеря данных если отставание минимальное.
Да и с асинхронной так и не уложу в голове где потеря данных если отставание минимальное.
П
А если реплика синхронная?
Да и с асинхронной так и не уложу в голове где потеря данных если отставание минимальное.
Да и с асинхронной так и не уложу в голове где потеря данных если отставание минимальное.
Т.е. я хочу сказать что потеря данных - она не от патрони, а от самой схемы работы асинхронной репликации)
ВК
Если готовы смириться с возможной потерей данных, используйте patroni.
BTW, сами создатели patroni своё детище в проде не используют.
BTW, сами создатели patroni своё детище в проде не используют.
Причём тут потеря при failover и патрони, это не от него зависит.
И нет, zalando плотно используют его.
И нет, zalando плотно используют его.
ВК
Т.е. я хочу сказать что потеря данных - она не от патрони, а от самой схемы работы асинхронной репликации)
Да. Но есть крутилки, для минимизации риска.
ВК
synchronous_mode: 'true'
synchronous_mode_strict: 'true'
synchronous_commit: 'remote_apply'
use_pg_rewind: 'false'
synchronous_mode_strict: 'true'
synchronous_commit: 'remote_apply'
use_pg_rewind: 'false'
П
Да. Но есть крутилки, для минимизации риска.
вы про maximum_lag_on_failover что если больше - то не переключаться на эту реплику?