о чем и речь

теперь нужно убить будет этот дэфолтный кластер, спасбо за помощь!

о чем и речь

я думал если полностью стопанул кластер, то к его конфигу уже не буде обращения и т.д.

Скажите, а запросы которые я делаю в pqsql они автоматом становятся prepared, или лучше их подготавливать?

Здравствуйте, я впервые работаю с большими базами. У меня сейчас есть база доменных имён (три столбца: id, имя, зона) Я добавил в базу ~44 миллиона записей. Теперь строю индексы: По зонам индекс на хеше ( данные можно востановить из другого источника, поэтому потери я не боюсь. По доменам, поскольку мне надо извлекать интервалы командой between - на деревьях. Серввер: 32 GB RAM, 8 cores Intel Xeon CPU, 500GB SSD. Кто-нибудь знает, сколько это примерно может занять времени?( часы, десятки часов, дни недели)

Здравствуйте, я впервые работаю с большими базами. У меня сейчас есть база доменных имён (три столбца: id, имя, зона) Я добавил в базу ~44 миллиона записей. Теперь строю индексы: По зонам индекс на хеше ( данные можно востановить из другого источника, поэтому потери я не боюсь. По доменам, поскольку мне надо извлекать интервалы командой between - на деревьях. Серввер: 32 GB RAM, 8 cores Intel Xeon CPU, 500GB SSD. Кто-нибудь знает, сколько это примерно может занять времени?( часы, десятки часов, дни недели)

а экспайн по запросу, что тебе говорит? оценивал?

44 миллиона - это не большая база

hash выкинь

опа! не успел про хэш отпечатать )))

hash выкинь

+++

Импорт такого должен занять десятки минут в худшем случае

Спасибо. EXPLAIN - На индексах не работает, насколько я знаю. EXPLAIN CREATE INDEX ON domains (name); ERROR: syntax error at or near "INDEX" LINE 1: EXPLAIN CREATE INDEX ON domains (name); https://stackoverflow.com/questions/34032896/postgresql-probabilities-explain-on-create-index Насчет хеша: 1) Чем он мне грозит, кроме меньшей безопасности данных? 2) Какой лучше использовать на 44 миллионах записей из которых уникальны ~ 100? ( Насколько я понимаю, если вынести их в отдельную таблицу и доставать с помощью JOIN по id - будет медленнее )

Всегда btree вместо hash

Или GIN? Если да, то какой именно?

А как ты gin создашь по этим данным?

Спасибо. EXPLAIN - На индексах не работает, насколько я знаю. EXPLAIN CREATE INDEX ON domains (name); ERROR: syntax error at or near "INDEX" LINE 1: EXPLAIN CREATE INDEX ON domains (name); https://stackoverflow.com/questions/34032896/postgresql-probabilities-explain-on-create-index Насчет хеша: 1) Чем он мне грозит, кроме меньшей безопасности данных? 2) Какой лучше использовать на 44 миллионах записей из которых уникальны ~ 100? ( Насколько я понимаю, если вынести их в отдельную таблицу и доставать с помощью JOIN по id - будет медленнее )

CREATE INDEX ON - утилитный запрос, explain там и не должен работать

>Импорт такого должен занять десятки минут в худшем случае. Перед импортом я дропнул хеши. Индекс строится уже часа 3. Диск правда грузится, база растёт на несколько мегабайт в час. Поскольку управляю всем из питона (sqlalchemy), то не могу понять толи проблема в питоне, толи в том, что они и должны так строится. >А как ты gin создашь по этим данным? CREATE INDEX idx_domains_name ON domains USING gin(name); Или тут подвох? Насколько я знаю GIN полнотекстовый, т.е. сомневаюсь, что он оптимален здесь.

*база растёт на несколько мегабайт в час. В час на пару десятков ( после первого часа)

Хеш не работает, выбрось и замени btree

gin нужен правильный opclass

Чтобы было, что инвертировать

Спасибо. Просто для справки: хеш это индекс, который вообще не построить на большой таблице? ( в документации сказано только про то, что это не безопасно для данных) >gin нужен правильный opclass >Чтобы было, что инвертировать Я и пришел к выводу, что если в базе нет имён доменов больше 7ми символов и я выполняю Beetween на 40 строк, GIN - не нужен. Убираю хеш, отпишу результат. Я правильно понимаю, что если такой индекс строится часами, то что-то не так?

Огромное спасибо. Проблема была в хешах.

Всё построилось

??

Привет. Подскажите пожалуйста, почему не используются индексы. Есть таблицы phone_numbers и locations, есть колонки с типом tsvector по которым необходимо производить поиск по тексту. если есть OR, как в примере запроса ниже, то индексы не используются SELECT * FROM phone_numbers JOIN locations ON phone_numbers.location_id = locations.id WHERE locations.searchable_vector @@ to_tsquery('mos:*') OR phone_numbers.searchable_vector @@ to_tsquery('205');

индексы CREATE INDEX phone_numbers_search_vector_index ON public.phone_numbers USING gin (searchable_vector); CREATE INDEX locations_search_vector_index ON public.locations USING gin (searchable_vector);

Не большой спец в постгре - но может вместо OR сделать 2 запроса и объединить результат через UNION ALL?

Тогда и индексы должны работать

я вчера собрал из последней ревизии pgadmin4 в режиме приложения и сегодня пробовал в нем работать. итог - на текущий момент оно сырое, неудобное и тяжелое. из забавных особенностей - нельзя открывать папки с кириллическими именами, не работает autorollback (хорошо, что отключение autocommit работает нормально), нет кнопок commit/rollback (только командами), автодоплнение работает только в uppercase, принудительно перевести в нижний регистр функции нет. Ну и завелось оно только после небольших правок сишной части проекта (проброс виртуального окружения болеет, но в redmine есть задача переписать эту часть кода). Как итог, я сильно сомневаюсь, что pgadmin4 будет готов для нормального использования к выходу десятки.

Всем привет. Вопрос: "как поступить лучше - в отдельные схемы или всё оставить в схеме public?" Есть у меня следующие Финансвоая часть. Полностью изолированные 4 таблицы, отвечающие только за движение средств. Не связаны ни с чем кроме как между собой Картотека. Полностью изолированные 3 таблицы, отвечающие за информацию о пользователе. Такие сущности как контактные данные, телефоны, юр/физ лицо, день рождения и прочее Пользователи: Полностью изолированные 6 таблиц, отвечающие за информацию по авторизации. Адресная база: Полностью изолированные 8 таблиц, содержащие информацию об адресах Таких групп таблиц более 10 и каждая отвечает за какую либо самостоятельную логику у каждой есть процедуры, вьюхи для распределения прав на основе роли пользователя в БД Также есть таблицы многие кол многим для связи этих групп таблиц. Дикое желание сделать по схеме на каждую группу таблиц. Провести рефакторинг процедур, перенеся туда изолированные. В паблике оставить только таблицы многие ко многим и общие процедуры. Но: а) многие фреймворки не умеют кастомно работать со схемами. б) не знаю насколько это плохо со стороны архитектуры

Всем привет. Вопрос: "как поступить лучше - в отдельные схемы или всё оставить в схеме public?" Есть у меня следующие Финансвоая часть. Полностью изолированные 4 таблицы, отвечающие только за движение средств. Не связаны ни с чем кроме как между собой Картотека. Полностью изолированные 3 таблицы, отвечающие за информацию о пользователе. Такие сущности как контактные данные, телефоны, юр/физ лицо, день рождения и прочее Пользователи: Полностью изолированные 6 таблиц, отвечающие за информацию по авторизации. Адресная база: Полностью изолированные 8 таблиц, содержащие информацию об адресах Таких групп таблиц более 10 и каждая отвечает за какую либо самостоятельную логику у каждой есть процедуры, вьюхи для распределения прав на основе роли пользователя в БД Также есть таблицы многие кол многим для связи этих групп таблиц. Дикое желание сделать по схеме на каждую группу таблиц. Провести рефакторинг процедур, перенеся туда изолированные. В паблике оставить только таблицы многие ко многим и общие процедуры. Но: а) многие фреймворки не умеют кастомно работать со схемами. б) не знаю насколько это плохо со стороны архитектуры

Адресная база 107 таблиц. Прошу прощения

Всем привет. Вопрос: "как поступить лучше - в отдельные схемы или всё оставить в схеме public?" Есть у меня следующие Финансвоая часть. Полностью изолированные 4 таблицы, отвечающие только за движение средств. Не связаны ни с чем кроме как между собой Картотека. Полностью изолированные 3 таблицы, отвечающие за информацию о пользователе. Такие сущности как контактные данные, телефоны, юр/физ лицо, день рождения и прочее Пользователи: Полностью изолированные 6 таблиц, отвечающие за информацию по авторизации. Адресная база: Полностью изолированные 8 таблиц, содержащие информацию об адресах Таких групп таблиц более 10 и каждая отвечает за какую либо самостоятельную логику у каждой есть процедуры, вьюхи для распределения прав на основе роли пользователя в БД Также есть таблицы многие кол многим для связи этих групп таблиц. Дикое желание сделать по схеме на каждую группу таблиц. Провести рефакторинг процедур, перенеся туда изолированные. В паблике оставить только таблицы многие ко многим и общие процедуры. Но: а) многие фреймворки не умеют кастомно работать со схемами. б) не знаю насколько это плохо со стороны архитектуры

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

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

Круто, то есть лично ты одобряешь?

Круто, то есть лично ты одобряешь?

Вполне! ?

Всем привет. Вопрос: "как поступить лучше - в отдельные схемы или всё оставить в схеме public?" Есть у меня следующие Финансвоая часть. Полностью изолированные 4 таблицы, отвечающие только за движение средств. Не связаны ни с чем кроме как между собой Картотека. Полностью изолированные 3 таблицы, отвечающие за информацию о пользователе. Такие сущности как контактные данные, телефоны, юр/физ лицо, день рождения и прочее Пользователи: Полностью изолированные 6 таблиц, отвечающие за информацию по авторизации. Адресная база: Полностью изолированные 8 таблиц, содержащие информацию об адресах Таких групп таблиц более 10 и каждая отвечает за какую либо самостоятельную логику у каждой есть процедуры, вьюхи для распределения прав на основе роли пользователя в БД Также есть таблицы многие кол многим для связи этих групп таблиц. Дикое желание сделать по схеме на каждую группу таблиц. Провести рефакторинг процедур, перенеся туда изолированные. В паблике оставить только таблицы многие ко многим и общие процедуры. Но: а) многие фреймворки не умеют кастомно работать со схемами. б) не знаю насколько это плохо со стороны архитектуры

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

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

Эм... чем замучаюсь?

Эм... чем замучаюсь?

Поддерживать весь зоопарк схем. Если их 10-20 то ещё норм, а вот если сотня - у тебя даже дапм тормозить будет.

Хм. А дамп на больше чем 500 таблиц быстрее будет.

Хм. А дамп на больше чем 500 таблиц быстрее будет.

Это не сарказм. Вполне серьезный вопрос.

И потом, когда дело касается прав, обычный дам уже не пашет нормально. Приходится юзать pg_dumpall. Но (как мне кажется) он работает несколько иначе, чем простая генерация SQL кода.

Поддерживать весь зоопарк схем. Если их 10-20 то ещё норм, а вот если сотня - у тебя даже дапм тормозить будет.

Но судя по сообщению, ты не сильно в восторге от такой архитектуры.

Но судя по сообщению, ты не сильно в восторге от такой архитектуры.

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

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

Понял. Спасибо за фидбек

Хм. А дамп на больше чем 500 таблиц быстрее будет.

поверь мне, да.

Пакеты нужны, чтобы не городить огород из схем

Пакеты нужны, чтобы не городить огород из схем

Не понял как их обслуживать

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

надо, чтобы пакеты были из коробки

...пакет с пакетами из коробки...

народ, а что за пакеты имеются в виду? Прошу прощения за идиЁЦЦкий вопрос.

Всем привет. Вопрос: "как поступить лучше - в отдельные схемы или всё оставить в схеме public?" Есть у меня следующие Финансвоая часть. Полностью изолированные 4 таблицы, отвечающие только за движение средств. Не связаны ни с чем кроме как между собой Картотека. Полностью изолированные 3 таблицы, отвечающие за информацию о пользователе. Такие сущности как контактные данные, телефоны, юр/физ лицо, день рождения и прочее Пользователи: Полностью изолированные 6 таблиц, отвечающие за информацию по авторизации. Адресная база: Полностью изолированные 8 таблиц, содержащие информацию об адресах Таких групп таблиц более 10 и каждая отвечает за какую либо самостоятельную логику у каждой есть процедуры, вьюхи для распределения прав на основе роли пользователя в БД Также есть таблицы многие кол многим для связи этих групп таблиц. Дикое желание сделать по схеме на каждую группу таблиц. Провести рефакторинг процедур, перенеся туда изолированные. В паблике оставить только таблицы многие ко многим и общие процедуры. Но: а) многие фреймворки не умеют кастомно работать со схемами. б) не знаю насколько это плохо со стороны архитектуры

В oracle схемы именно так и работают. Но в postgres'e схемы это скорее package, они не предназначены для изоляций. Можно конечно извратиться и использовать search path, но если реально разные не связанные сущности, то можно разделить вообще на разные базы

я вчера собрал из последней ревизии pgadmin4 в режиме приложения и сегодня пробовал в нем работать. итог - на текущий момент оно сырое, неудобное и тяжелое. из забавных особенностей - нельзя открывать папки с кириллическими именами, не работает autorollback (хорошо, что отключение autocommit работает нормально), нет кнопок commit/rollback (только командами), автодоплнение работает только в uppercase, принудительно перевести в нижний регистр функции нет. Ну и завелось оно только после небольших правок сишной части проекта (проброс виртуального окружения болеет, но в redmine есть задача переписать эту часть кода). Как итог, я сильно сомневаюсь, что pgadmin4 будет готов для нормального использования к выходу десятки.

у bigsql есть форк pgadmin3 с пометкой LTS: поддержка 9.6 и 10, отдельно скачать нельзя, но можно взять бинарник из установленной сборки

Добрый день! Больше месяца работала реплика, wal_keep_segments на мастере 128 Вчера ночью вдруг начала писать, что нужный фрагмент удален и репликация встала. Может кто-то подскажет куда смотреть?

у bigsql есть форк pgadmin3 с пометкой LTS: поддержка 9.6 и 10, отдельно скачать нельзя, но можно взять бинарник из установленной сборки

Не нашел вообще никаких отличий от последнего pgAdmin3

Только заставку свою вкрячили. По крайней мере касательно версии для Мак.

Только заставку свою вкрячили. По крайней мере касательно версии для Мак.

они вроде и не заявляли новые фичи, заставка работе не мешает)

на винде тоже только заставка

Я имел в виду, что ни одного бага не пофиксили.

Чем отличается эта версия от обычного pgAdmin? Заставкой и "якобы будущей поддержкой 10-й версии" Но при этом с 9-й версией как не работал (нормально), так и не работает.

один баг они точно пофиксили: когда вылетало соединение по таймауту в основном окне, переконнект приводил к вылету приложения

pg 10 вышел чтоли?

вышел, не вышел - использовать не мешает

Добрый день! Больше месяца работала реплика, wal_keep_segments на мастере 128 Вчера ночью вдруг начала писать, что нужный фрагмент удален и репликация встала. Может кто-то подскажет куда смотреть?

Добрый вечер. Смотреть какой сегмент хочет слейв и смотреть, есть ли он на мастере. Скорее всего его нет, т.к. сам Постгрес говорит об этом.

вышел, не вышел - использовать не мешает

но он стабильный хоть? (Сейчас 9.6 юзаю)

ну, у меня падает не страшнее 9.6

Добрый день! Больше месяца работала реплика, wal_keep_segments на мастере 128 Вчера ночью вдруг начала писать, что нужный фрагмент удален и репликация встала. Может кто-то подскажет куда смотреть?

слоты pg_archivecleanup

Добрый день! Больше месяца работала реплика, wal_keep_segments на мастере 128 Вчера ночью вдруг начала писать, что нужный фрагмент удален и репликация встала. Может кто-то подскажет куда смотреть?

Мне кажется, что вариант решения только один, догнать через rsync или pg_basebackup

Если не окажется архивных WALов

ну, у меня падает не страшнее 9.6

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

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

Мы особой разницы не заметили, кроме как в появлении Segmentation fault на параллельном скане))

Но, дай бог здоровья разработчикам, выход 9.6.5 решил эту проблему.

Привет, коллеги, подскажите, пожалуйста, можно ли увеличить скорость накатывания WAL-логов на хот стендбай при использовании потоковой репликации? Сейчас один WAL-лог накатывается за ~10 секунд. Сами логи и дата-файлы находятся на ssd, версия постгреса - 9.6.5, версия ОС - CentOS 6.9. Буду благодарен за любые подсказки!

Привет, коллеги, подскажите, пожалуйста, можно ли увеличить скорость накатывания WAL-логов на хот стендбай при использовании потоковой репликации? Сейчас один WAL-лог накатывается за ~10 секунд. Сами логи и дата-файлы находятся на ssd, версия постгреса - 9.6.5, версия ОС - CentOS 6.9. Буду благодарен за любые подсказки!

Чекпоинты как часто происходят?

Чекпоинты как часто происходят?

По умолчанию раз в полчаса, и если создалось 16 wal-файлов

Привет, коллеги, подскажите, пожалуйста, можно ли увеличить скорость накатывания WAL-логов на хот стендбай при использовании потоковой репликации? Сейчас один WAL-лог накатывается за ~10 секунд. Сами логи и дата-файлы находятся на ssd, версия постгреса - 9.6.5, версия ОС - CentOS 6.9. Буду благодарен за любые подсказки!

а потоковую репликацию почему не далаете?

У меня раз в час, посмотрите логи, если чекпоинты не слишком часто происходят, то тогда смотреть в сторону следующих параметров: synchronous_commit wal_buffers wal_writer_delay commit_delay

а потоковую репликацию почему не далаете?

Потоковую и делаем

У меня раз в час, посмотрите логи, если чекпоинты не слишком часто происходят, то тогда смотреть в сторону следующих параметров: synchronous_commit wal_buffers wal_writer_delay commit_delay

Хорошо ,спасибо. Не знаете, есть ли верхнее программное ограничение по скорости наката wal?

Потоковую и делаем

в потоковой журнал накатывается сразу по записям и не по файлам, как ты определил что 1 файл накатывается 10 секунд

synchronous_commit = off

в потоковой журнал накатывается сразу по записям и не по файлам, как ты определил что 1 файл накатывается 10 секунд

По лог-файлу

А fsync нежелательно отключать

По лог-файлу

Тогда лог-файл в студию!

в потоковой журнал накатывается сразу по записям и не по файлам, как ты определил что 1 файл накатывается 10 секунд

[2017-09-08 14:13:25 MSK u= d= h= p=3621 l=1199] LOG: restored log file "0000000100003FFD0000006B" from archive [2017-09-08 14:13:30 MSK u= d= h= p=3621 l=1200] LOG: restored log file "0000000100003FFD0000006C" from archive [2017-09-08 14:13:36 MSK u= d= h= p=3621 l=1201] LOG: restored log file "0000000100003FFD0000006D" from archive [2017-09-08 14:13:47 MSK u= d= h= p=3621 l=1202] LOG: restored log file "0000000100003FFD0000006E" from archive

А какой примерно объем данных прилетает каждые 10 секунд?

Где-то мегабайт 200-300

[2017-09-08 14:13:25 MSK u= d= h= p=3621 l=1199] LOG: restored log file "0000000100003FFD0000006B" from archive [2017-09-08 14:13:30 MSK u= d= h= p=3621 l=1200] LOG: restored log file "0000000100003FFD0000006C" from archive [2017-09-08 14:13:36 MSK u= d= h= p=3621 l=1201] LOG: restored log file "0000000100003FFD0000006D" from archive [2017-09-08 14:13:47 MSK u= d= h= p=3621 l=1202] LOG: restored log file "0000000100003FFD0000006E" from archive

может это не потоковая

Мне кажется, тут дело даже не в объеме данных, а именно в настройках параметров WAL журнала.

может это не потоковая

Самая что ни на есть потоковая

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

Если не потоковая, то логическая, но pglogical или Slony тут не видно :)

Пересобирать Постгрес для увеличения размера WAL? O_o

Поставить 128 мегабайт