она не совсем для новичка

для новичка самое хорошее это читать документацию, по-моему

для новичка самое хорошее это читать документацию, по-моему

+1 А то можно нарваться на что-то типа "PostgreSQL Development Essentials", и так "освоить" PostgreSQL, что мало не покажется. ;(

@Risel будет жить. Поприветствуем!

Ребят подскажите пожалуйста, что посмотреть/почитать новичку про postgresql?

Быстрее всего тут. https://www.youtube.com/channel/UCawnwMqZ6JeoSiEhrS6X69A А потом уже по ситуации.

она не совсем для новичка

Вы знаете, это зависит от способностей новичка ?

вышел PostGIS 2.5.0: http://postgis.net/2018/09/23/postgis-2.5.0/

Sergei будет жить. Поприветствуем!

Доброго времени суток , настроил постгрес врапер где беру дату с ms sql , селект работает, но когда добовляю where фильтр он просто игнорируется , в чем может быть проблема ?

Доброго времени суток , настроил постгрес врапер где беру дату с ms sql , селект работает, но когда добовляю where фильтр он просто игнорируется , в чем может быть проблема ?

Я таки читаю данное предложение следующим образом: я настроил postgres_fdw для доступа к MS SQL. Селект работает, а where фильтр игнорируется. Вы бы указали, что именно настроили, и как.

Ибо postgres_fdw предназначен для доступа к другому постгресу, а не к иным СУБД. К иным СУБД нужен иной враппер.

tds-fdw с посгреса к view от ms sql.

сделал все по инструкции https://github.com/tds-fdw/tds_fdw

сделал все по инструкции https://github.com/tds-fdw/tds_fdw

Ну а логи смотрели? А на стороне MS SQL?

Ну а логи смотрели? А на стороне MS SQL?

В логах ничего , ошибку ведь не выдает.

В логах ничего , ошибку ведь не выдает.

При чём тут ошибка? Логи — на максимум, и посмотреть, что выдаёт вообще. ;) Если ничего подозрительного, то посмотреть, что там со стороны MS SQL происходит.

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

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

https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes/

> Стоит вопрос об использования uuid для pk, по причине распределенной архитектуры приложения. Как одно (использование uuid для pk) с другим (распределенная архитектура) связано, в Вашем случае?

> Стоит вопрос об использования uuid для pk, по причине распределенной архитектуры приложения. Как одно (использование uuid для pk) с другим (распределенная архитектура) связано, в Вашем случае?

Бывает очень часто, что необходимо знать id создаваемой сущности заранее. Ну и так же планируется шардинг бд.

https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes/

Если абсолютно рандомный uuid то это ожидаемо. А вот если использовать uuid v1? Он не совсем рандомный же, а вначале использует timestamp когда он был сгенерирован и индентификатор генератора. Cможет ли постгрес воспользоваться для оптимизации индекса этой особенностью?

Если абсолютно рандомный uuid то это ожидаемо. А вот если использовать uuid v1? Он не совсем рандомный же, а вначале использует timestamp когда он был сгенерирован и индентификатор генератора. Cможет ли постгрес воспользоваться для оптимизации индекса этой особенностью?

Эээ... а как это поможет в случае "частично на стороне приложения"? Там же "involves the MAC address of the computer and a time stamp." Кстати, для random UUID, full page writes — не единственная пакость, которая Вас может ожидать (зависит от отношения размера индексов к RAM, впрочем). (Получаются фрагментированные индексы, которые не коррелированы с heap. Ещё и естественная корреляция момента вставки со значением PK и вероятностью использования исчезает, что тоже может быть нехорошо).

Эээ... а как это поможет в случае "частично на стороне приложения"? Там же "involves the MAC address of the computer and a time stamp." Кстати, для random UUID, full page writes — не единственная пакость, которая Вас может ожидать (зависит от отношения размера индексов к RAM, впрочем). (Получаются фрагментированные индексы, которые не коррелированы с heap. Ещё и естественная корреляция момента вставки со значением PK и вероятностью использования исчезает, что тоже может быть нехорошо).

Вот именно это я и пытаюсь обойти. А если генерировать uuid v1 исключительно в приложении, решит ли это проблему?

Если абсолютно рандомный uuid то это ожидаемо. А вот если использовать uuid v1? Он не совсем рандомный же, а вначале использует timestamp когда он был сгенерирован и индентификатор генератора. Cможет ли постгрес воспользоваться для оптимизации индекса этой особенностью?

А как ты предполагаешь должна происходить эта оптимизация?

А как ты предполагаешь должна происходить эта оптимизация?

Никак не предполагаю, как создается индекс я чисто поверхностно теоретически знаю.

Вот именно это я и пытаюсь обойти. А если генерировать uuid v1 исключительно в приложении, решит ли это проблему?

Ну, в общем-то фрагментация индексов, даже если она случится, такая себе проблема...

Вот именно это я и пытаюсь обойти. А если генерировать uuid v1 исключительно в приложении, решит ли это проблему?

Были же вроде какие-то ещё sequential UUIDs (не v1), не искали (я сам не пользовался, не подскажу)?

Никак не предполагаю, как создается индекс я чисто поверхностно теоретически знаю.

Сортируются данные. Укладываются в сбаллансированное дерево B+tree. (количество поднод на странице произвольное). Всё. Как тут поможет твой UUID?

Были же вроде какие-то ещё sequential UUIDs (не v1), не искали (я сам не пользовался, не подскажу)?

Ладно, допустим, у меня уже есть seq uuids которые я генерю на стороне приложения. Поможет ли это постгресу не фрагментировать хранение индекса?

Ладно, допустим, у меня уже есть seq uuids которые я генерю на стороне приложения. Поможет ли это постгресу не фрагментировать хранение индекса?

Ну, возможно, поможет слегка. И что? Фрагментация всё равно будет возможна.

Сортируются данные. Укладываются в сбаллансированное дерево B+tree. (количество поднод на странице произвольное). Всё. Как тут поможет твой UUID?

Так, что вставки пойдут в последний лист, а не неведомо куда. > Ну, возможно, поможет слегка. Поможет очень прилично. Одну ссылку выше уже приводили.

Ладно, допустим, у меня уже есть seq uuids которые я генерю на стороне приложения. Поможет ли это постгресу не фрагментировать хранение индекса?

Ты зря про это вообще думаешь. Будет фрагментация уж такая сильная -- пересоздашь индекс и всё.

Ладно, допустим, у меня уже есть seq uuids которые я генерю на стороне приложения. Поможет ли это постгресу не фрагментировать хранение индекса?

Если они действительно sequential — поможет, да. Потому что v1 — только частично. Вот я сейчас два раза вызвал uuid_generate_v1(): "fcc1a5fe-bfde-11e8-b978-1f94b6d2c6f7" "0204a2dc-bfdf-11e8-b97c-df898960e444" Как-то не очень sequential. ;)

Если они действительно sequential — поможет, да. Потому что v1 — только частично. Вот я сейчас два раза вызвал uuid_generate_v1(): "fcc1a5fe-bfde-11e8-b978-1f94b6d2c6f7" "0204a2dc-bfdf-11e8-b97c-df898960e444" Как-то не очень sequential. ;)

не, это рандомный, там еще есть функция

Ты зря про это вообще думаешь. Будет фрагментация уж такая сильная -- пересоздашь индекс и всё.

Так проблема при вставке от этого никуда не уйдёт. Так же как и проблема корреляции index/heap.

не, это рандомный, там еще есть функция

Какая, конкретно?

Какая, конкретно?

я ошибся, у вас все правильно, я с uuid_generate_v1mc() перепутал

Если они действительно sequential — поможет, да. Потому что v1 — только частично. Вот я сейчас два раза вызвал uuid_generate_v1(): "fcc1a5fe-bfde-11e8-b978-1f94b6d2c6f7" "0204a2dc-bfdf-11e8-b97c-df898960e444" Как-то не очень sequential. ;)

Не, все не так плохо

Это и есть "плохо" — совсем не то, что sequential. В плане производительности это не сильно лучше random.

Это и есть "плохо" — совсем не то, что sequential. В плане производительности это не сильно лучше random.

Но ведь начало же sequential, постгрес все равно будет такое фрагментировать?

Но ведь начало же sequential, постгрес все равно будет такое фрагментировать?

Так там всё равно будет wrap (это как если бы старший разряд в числе менялся). Т.е. на таблицах сколько-нибудь существенного размера — никакой разницы... если не хуже. ;)

@sqddy будет жить. Поприветствуем!

Но ведь начало же sequential, постгрес все равно будет такое фрагментировать?

Если только в PG будет специальный вид сотрировки под этот тип данных...

Если только в PG будет специальный вид сотрировки под этот тип данных...

Да вроде бы обычная / ожидаемая (как выводится, так и сортируется).

@Rusicko будет жить. Поприветствуем!

А что мешает сделать pk bigint? Выделить младший байт или пару на идентификатор сервера, а остальное - счётчик. Никогда не пересекутся, всегда известно откуда ключ. Не надо возиться с монструозного вида варчарами - база зазря не пухнет

А что мешает сделать pk bigint? Выделить младший байт или пару на идентификатор сервера, а остальное - счётчик. Никогда не пересекутся, всегда известно откуда ключ. Не надо возиться с монструозного вида варчарами - база зазря не пухнет

Так им вроде нужно на клиенте генерировать.... А причём тут varchar?

Так им вроде нужно на клиенте генерировать.... А причём тут varchar?

Это не проблема. А что суть uuid как не варчар?

Это не проблема. А что суть uuid как не варчар?

> Это не проблема. Хмм... а по-моему, проблема. Уникальность-то нужно обеспечить? > А что суть uuid как не варчар? Тип такой, 16-байтный.

> Это не проблема. Хмм... а по-моему, проблема. Уникальность-то нужно обеспечить? > А что суть uuid как не варчар? Тип такой, 16-байтный.

Если сервера разные, то вы поди знаете на каком вы сейчас и маска его известна. А уж узнать последнее значение ключа совсем не проблема

> А уж узнать последнее значение ключа совсем не проблема Каким образом, без обращения к серверу (PostgreSQL) вообще?

В базу данные тоже без участия сервера будут попадать?

В базу данные тоже без участия сервера будут попадать?

Им нужно вставлять уже сгенерированный на клиенте уникальный идентификатор, я так понял. (Зачем конкретно / почему это критично, я так и не понял.) ;) Для чего и хотели использовать UUID...

Но ведь начало же sequential, постгрес все равно будет такое фрагментировать?

А почему Вам так важно, чтобы на клиенте, кстати? ;)

Так если вставлять куда бы то ни было в базу, то доступ к ней есть ))

иногда необходимо обеспечить железную идемпотентность операции

Привет всем =) Можете ответить нубу, при логической репликации, данные, которые инсертятся напрямую в slave(ноду с subscription), не реплицируются обратно на мастер? И второе, можно ли этого добиться при логической реплике?

вы хотите сделать мультимастер, но вряд ли вы захотите действительно иметь такую систему в проде

Хотелось бы. По следующей причине: просто я не понимаю, как у моих прилаг разделить операции, чтения и записи, чтобы они ходили в разные ноды(конкретные)

Привет всем =) Можете ответить нубу, при логической репликации, данные, которые инсертятся напрямую в slave(ноду с subscription), не реплицируются обратно на мастер? И второе, можно ли этого добиться при логической реплике?

Эээ... Вы два раза употребили слово "логической"... Вы точно это хотели спросить?

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

Эээ... Вы два раза употребили слово "логической"... Вы точно это хотели спросить?

Наверное, да. Можно кратко написать мой вопрос так, можно ли в мастер-мастер при логической репликации? =)

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

Если это так -я могу оставить, как есть. Но я не понимаю, к сожалению, как балансировать нагрузку на мастер и реплику.

Наверное, да. Можно кратко написать мой вопрос так, можно ли в мастер-мастер при логической репликации? =)

Можно всё, что угодно, даже гланды через анус автогеном удалять. Вопрос в другом: а оно надо?

Если это так -я могу оставить, как есть. Но я не понимаю, к сожалению, как балансировать нагрузку на мастер и реплику.

Либо на уровне приложения, либо по через plproxy

Но во втором случае балансироваться будут только вызовы функций.

Можно всё, что угодно, даже гланды через анус автогеном удалять. Вопрос в другом: а оно надо?

Как быстрое решение, оно было бы надо. Но если это звучит, как удаление гланд, через то самое - то я задумаюсь, стоит ли так делать =)

Наверное, да. Можно кратко написать мой вопрос так, можно ли в мастер-мастер при логической репликации? =)

Хмм... ну ладно. > не реплицируются обратно на мастер? Нет, не реплицируются. > И второе, можно ли этого добиться при логической реплике? Добиться бесконечного цикла обновлений? Не знаю, даже не пытался пробовать. :) > можно ли в мастер-мастер при логической репликации? =) Зачем?! Master-master — это не волшебный порошок, который Вам что-то там "улучшит". Будет совсем наоборот. Хотя... если на данные Вам, по большому счёту, пофиг, можно что-то "сварить", наверное... :(

Ясно, я понял. Спасибо, за ответы =) Тогда сделаю следующее: переключу слейв в read only( пока не знаю как). И напишу у прилаг кастомный слой, который разделяет select и update операции.

Ясно, я понял. Спасибо, за ответы =) Тогда сделаю следующее: переключу слейв в read only( пока не знаю как). И напишу у прилаг кастомный слой, который разделяет select и update операции.

Вообще-то replication в PostgreSQL не full-ACID (неважно, синхронная или асинхронная, логическая или физическая). (Тут недавно давали ссылку на доклад, хотя это и так описано в документации). Зачем Вам вообще логическая репликация (а не физическая, например)?

Хочу не все реплицировать. Да и попробовать =)

Хочу не все реплицировать. Да и попробовать =)

разделять read/write запросы как-то умеет pgpool. Но действительно с репликацией много нюансов: если не прилагать специальных усилий то приложение может при таком подходе не увидеть собсвенные изменения.

Хочу не все реплицировать. Да и попробовать =)

> Хочу не все реплицировать. Тогда да, можно попробовать. Но DDL в таком случае становится Вашей проблемой. ;)

разделять read/write запросы как-то умеет pgpool. Но действительно с репликацией много нюансов: если не прилагать специальных усилий то приложение может при таком подходе не увидеть собсвенные изменения.

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

> Хочу не все реплицировать. Тогда да, можно попробовать. Но DDL в таком случае становится Вашей проблемой. ;)

Это да, но у меня ликвибейз на прилагах, подумаю, как автоматом через них ddl применять.

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

В общем случае, 100% корректные данные можно прочитать только с master (актуальные или нет, неважно). Если это не очень важно, репликация подойдёт.

подскажите почему pg_dump может зависать? запускаю из докер контейнера дамп базы. дамп доходит до размера 40 мб и все. сама pg_dump висит. убиваю pg_dump и запускаю снова. Дамп проходит до размера больше. И так до тех пор пока не сделается норм дамп и pg_dump не завершится ок. место на диске есть. база в момент дампа используется но не очень нагруженно.

подскажите почему pg_dump может зависать? запускаю из докер контейнера дамп базы. дамп доходит до размера 40 мб и все. сама pg_dump висит. убиваю pg_dump и запускаю снова. Дамп проходит до размера больше. И так до тех пор пока не сделается норм дамп и pg_dump не завершится ок. место на диске есть. база в момент дампа используется но не очень нагруженно.

> сама pg_dump висит. А в pg_stat_activity в это время про него что пишут?

сейчас перезапустил и дамп пока идет. в табличке статус active. как остановится снова посмотрю статус. не знал про эту табличку) спасибо

коллеги, добрый вечер. Подскажите пожалуйста где должны лежать расширения ? хочу поставить smlar (https://railsware.com/blog/2012/05/10/effective-similarity-search-in-postgresql/)

CREATE EXTENSION smlar; ругается на отсутствие файла в extensions, складываю файлики туда, ругается на отсутствие папки smlar (а она там лежит)

CREATE EXTENSION smlar; ругается на отсутствие файла в extensions, складываю файлики туда, ругается на отсутствие папки smlar (а она там лежит)

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

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

вопрос где должны лежать расширения

вопрос где должны лежать расширения

там где вы указали их держать при компиляции postgres

там где вы указали их держать при компиляции postgres

спасибо за ответ! Немного не понял про компиляцию postgres

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

например у меня: > create extension xxx; ERROR: could not open extension control file "/usr/share/postgresql-9.4/extension/xxx.control": Нет такого файла или каталога