Вам сверху скинули ссылку на доку

Либо можно совсем по другому. Через pg_try_advistory_xact() в WHERE. Как это делается - в поиск.

спасибо

Коллеги, а кто как управляет версионированием схемы базы данных? Какие используете системы выката (и отката) обновлений схемы и данных?

Так зачем вы всё это делаете, если не секрет? Или просто разобраться хотите?

Реальная проблема на проекте с 2.5 землекомпами

Реальная проблема на проекте с 2.5 землекомпами

Ну так я и спрашивал, какая у вас цель? А то вы только про средства...

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

вроде бы всю инфу получил. но уперлось в union all, об этом тоже писали, пока думаю

Ну просто обработай по порядку все часть UNION

Ты же всё равно UPDATE в одной из нескольких таблиц будешь делать, правильно?

да, кстати union по одной и той же таблице

Тогда его можно просто убрать

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

Это именно то, о чём я пишу. Это не цель, а средство для решения какой-то задачи. Какой?

Заменив на OR

Это именно то, о чём я пишу. Это не цель, а средство для решения какой-то задачи. Какой?

Ну таски какие-то он явно обрбатывает

Заменив на OR

нет подойдёт, либо я слишком сложно смотрю на вещи

Ну таски какие-то он явно обрбатывает

Так вроде он говорил, что нет... или я не так понял.

нет подойдёт, либо я слишком сложно смотрю на вещи

Не может не пойти

Запрос с UNION ALL всегда можно расписать без UNION ALL, но с OR.

нельзя, если селект из разных таблиц

И наоборот, но UNION уже может быть не ALL..

нельзя, если селект из разных таблиц

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

Запрос с UNION ALL всегда можно расписать без UNION ALL, но с OR.

Есть 3 типа "тасков" new,in-progress,ready, интересуют только new и in-progress сначала я получаю new, потом добавляю in-progress, которые недоделаныые пользователеми(висят на них долго, потом добавляю in-progress, которые на текущем пользователе) и всё это из одной табилцы, для каждого блока "недоделанных" и "заброшенных" есть свои условия выборки, по этому я не представляю как это сделать без union

or, in , ...

короч, скину лара-код, иначе не объяснишь.

А с чем связано, что достаточно не тривиально поменять порядок столбцов в таблице? Или сделать alter с указанием в какую позицию добавить столбец. В чем тут вся сложность заключается, что этого нет в postgresql?

Или можно?

А с чем связано, что достаточно не тривиально поменять порядок столбцов в таблице? Или сделать alter с указанием в какую позицию добавить столбец. В чем тут вся сложность заключается, что этого нет в postgresql?

А зачем его вообще менять? Смысл? Он ни на что не влияет.

А с чем связано, что достаточно не тривиально поменять порядок столбцов в таблице? Или сделать alter с указанием в какую позицию добавить столбец. В чем тут вся сложность заключается, что этого нет в postgresql?

Нельзя, только если новую таблицу создать. Связано с тем как физически хранятся данные. Нигде нет отображения что столбец aaa это на диске 15-ое поле. Потому что такое отображение было бы лишними накладными расходами, приходилось бы одно в другое мапить.

А зачем его вообще менять? Смысл? Он ни на что не влияет.

+1 правило хорошего тона писать точно какие поля и в каком порядке ты хочешь в select'е, не select *

иначе проблемы - при изменении схемы ломается приложение

Да да да

На самом деле про aaa = 15 поле я плохо написал, на самом деле в каталоге есть именно это отображение

Но если менять порядок, то придется обновлять все таплы. ИЛИ иметь отображение что 15-ое поле на самом деле теперь как бы 14-ое. Вот этого второго отображения нет

Есть 3 типа "тасков" new,in-progress,ready, интересуют только new и in-progress сначала я получаю new, потом добавляю in-progress, которые недоделаныые пользователеми(висят на них долго, потом добавляю in-progress, которые на текущем пользователе) и всё это из одной табилцы, для каждого блока "недоделанных" и "заброшенных" есть свои условия выборки, по этому я не представляю как это сделать без union

А, так это всё-таки очередь... Тогда почему бы вам не поискать готовые решения вместо того, чтобы изобретать велосипед? http://skytools.projects.postgresql.org/doc/pgq-sql.html http://www.depesz.com/2013/08/30/pick-a-task-to-work-on/ http://johtopg.blogspot.com.br/2015/01/queues-queues-they-all-fall-down.html

А с чем связано, что достаточно не тривиально поменять порядок столбцов в таблице? Или сделать alter с указанием в какую позицию добавить столбец. В чем тут вся сложность заключается, что этого нет в postgresql?

Связано с тем, что это в 99% случаев бесполезное крохоборство. ;)

Но если менять порядок, то придется обновлять все таплы. ИЛИ иметь отображение что 15-ое поле на самом деле теперь как бы 14-ое. Вот этого второго отображения нет

А просто в конструкцию select * это учитывать не меняя физически хранение? Вообще я согласен про явное указание полей, но было интересно, может есть какая то логика и поэтому оно именно так

А просто в конструкцию select * это учитывать не меняя физически хранение? Вообще я согласен про явное указание полей, но было интересно, может есть какая то логика и поэтому оно именно так

Если не согласен, то тебе должно быть пофиг на порядок полей...

А просто в конструкцию select * это учитывать не меняя физически хранение? Вообще я согласен про явное указание полей, но было интересно, может есть какая то логика и поэтому оно именно так

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

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

Просто "SELECT *" не место в production коде (и я подозреваю, что committer-ы считают так же). Так что — только время потратите, IMHO.

Есть мнение, что использовать SELECT * так же естественно, как и C++ ?

а сможете раскрыть мысль? :)

Просто "SELECT *" не место в production коде (и я подозреваю, что committer-ы считают так же). Так что — только время потратите, IMHO.

Я про select * диаметрально противоположного мнения, но если ты используешь SELECT *, то, очевидно, нужные поля тебе ты обязан искать по именам.

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

а сможете раскрыть мысль? :)

Мысль: "использовать с осторожностью".

Я про select * диаметрально противоположного мнения, но если ты используешь SELECT *, то, очевидно, нужные поля тебе ты обязан искать по именам.

Хмм... почему? (Я к тому, что это одна из общеизвестных bad practices (вообще для всех RDBMS, наверное), и есть аргументы в пользу такого утверждения.)

Коллеги, а можно как-то отсортировать по второму уровню jsonb? Например { "tags": { "name": "Max" } }

да

order by json->'tags'->>'name'

order by json->'tags'->>'name'

а по второму уровню?

Хмм... почему? (Я к тому, что это одна из общеизвестных bad practices (вообще для всех RDBMS, наверное), и есть аргументы в пользу такого утверждения.)

Ты просто bad practice не там ищеш.

а по второму уровню?

исправил

Хмм... почему? (Я к тому, что это одна из общеизвестных bad practices (вообще для всех RDBMS, наверное), и есть аргументы в пользу такого утверждения.)

Проблема не в непредсказуемости набора полей набора данных, а в том, как приложение ищет нужные ему поля в этом наборе.

исправил

Спасибо! Я в первом ставил -> по невнимательности

Проблема не в непредсказуемости набора полей набора данных, а в том, как приложение ищет нужные ему поля в этом наборе.

Проблема не только в этом... опять-таки, я думаю, аргументы легко найти в google. ;)

Проблема только в этом. А в гугле можно найти любую ерунду.

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

генерировать липовые данные не очень интересно и лень, может есть что-то готовое

желательно не больше 10ГБ в сжатом виде

Ну, можно посоветовать tpc-h...

http://www.tpc.org/tpc_documents_current_versions/download_programs/tools-download-request.asp?bm_type=TPC-H&bm_vers=2.17.3&mode=CURRENT-ONLY Это?

это что-то вроде тулзы генерирующей данные?

ERROR: S client not available

Попробуй найти, должно быть быстрее, чем генерить данные

Я пытался, но везде либо гавно мамонта 2008 года, либо базы на 100500ТБ которые мне на диск даже не влезут. :(

Если нацелен на а таблички по 100млн, это будет долговато

2008 это что?

Типо не мог развернуть или что?

аналог saqila и dell store

там вообще идут *.exe файлы для заливки, если я правильно понял

?

может я и ошибаюсь, http://linux.dell.com/dvdstore/

вот короче

Скачай для начала какую-нибудь небольшую базу интернет магазина

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

https://postgrespro.ru/education/demodb

Скачай для начала какую-нибудь небольшую базу интернет магазина

хех, где бы её взять))) я как раз в идеале и ищу интернет-магазин

See readme.txt for more details

подскажите autovacuum_analyze_scale_factor задается от размера таблицы, а с учетом индексов или без?

https://postgrespro.ru/education/demodb

о, спасибо.

https://postgrespro.ru/education/demodb

Красота

хех, где бы её взять))) я как раз в идеале и ищу интернет-магазин

Даркнет?))

Даркнет?))

я даже не думал об этом. но идея годная. главное чтоб пативен не выехал за мной

Да ну вряд ли, у них уже такие базы есть)

подскажите autovacuum_analyze_scale_factor задается от размера таблицы, а с учетом индексов или без?

и еще если по таблице небыло вакуума то значит в ней много dead tuples строк, то значит ее размер может быть слишком завышенным, что бы вновь добавленные строки не смогли вызвать аналайз и автовакуум?

Коллеги, а кто как управляет версионированием схемы базы данных? Какие используете системы выката (и отката) обновлений схемы и данных?

Что, совсем никто не версионирует схему базы данных?

Что, совсем никто не версионирует схему базы данных?

я использую knex.js и почти доволен

я использую knex.js и почти доволен

Это скорее конструктор запросов. Не то, что нужно. Интересует именно система контроля версий схемы БД и механизм наката изменений и отката в случае ошибки. Как пример - https://habr.com/post/121265/

там есть миграционный тул

но его имеет смысл юзать, если само приложение на ноде(как у нас)

типа рельсовых миграций

Коллеги, а wal-g в связке с minio(совместимое с s3 хранилище) юзает кто? Брат жив здоров?

там есть миграционный тул

Ок, спасибо. Попробуем. Ни у кого больше нету рабочих примеров?

Ок, спасибо. Попробуем. Ни у кого больше нету рабочих примеров?

Я слышал про https://sqitch.org/ , например.

https://github.com/yandex/pgmigrate