надо упасть и делать рекавери

да, хороший вариант

точнее промоут стендбая

это всегда хороший вариант

у тебя ещё и стендбай есть!

ну да) хотелось бы

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

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

А толку? Просто уходите с linux (ужас в thread-е в том, что на данный момент linux kernel hacker _и не собираются_ это исправлять). ;)

Да, Линукс ужасная операционная система...

Да, Линукс ужасная операционная система...

И, похоже, не только он: https://www.postgresql.org/message-id/CAEepm%3D0B9f0O7jLE3ipUTqC3V6NO2LNbwE9Hp%3D3BxGbZPqEyQg%40mail.gmail.com

Да, Линукс ужасная операционная система...

Блин, я что-то не посмотрел, 1ое апреля же уже кончилось...

Доброе утро, уважаемые коллеги! Ваша дискуссия безумно интересна, но чисто в академических целях. Мы же людишки мелкие, на земле трудимся, нам более практичныех вопросов обсуждать интересно. А именно. Есть необходимость ограничить текстовое поле по длине. На стороне приложения проверка присутствует. Внимание, вопрос: что дешевле с точки зрения потребления ресурсов и быстрее по скорости: в хранимке тупо обрезать лишнее, или на эти поля повесить CHECK? Особенно с учётом того, что, согласно документации https://postgrespro.ru/docs/postgresql/10/plpgsql-control-structures Наличие секции EXCEPTION значительно увеличивает накладные расходы на вход/выход из блока. Поэтому не используйте EXCEPTION без надобности.

как дропнуть столбец в определнной таблице?

как дропнуть столбец в определнной таблице?

alter table tablename drop column columnname если есть констрейны, то перед этим alter table tablename alter column columnname drop contstrain

как дропнуть столбец в определнной таблице?

Alter table table_name drop column column for name

Доброе утро, уважаемые коллеги! Ваша дискуссия безумно интересна, но чисто в академических целях. Мы же людишки мелкие, на земле трудимся, нам более практичныех вопросов обсуждать интересно. А именно. Есть необходимость ограничить текстовое поле по длине. На стороне приложения проверка присутствует. Внимание, вопрос: что дешевле с точки зрения потребления ресурсов и быстрее по скорости: в хранимке тупо обрезать лишнее, или на эти поля повесить CHECK? Особенно с учётом того, что, согласно документации https://postgrespro.ru/docs/postgresql/10/plpgsql-control-structures Наличие секции EXCEPTION значительно увеличивает накладные расходы на вход/выход из блока. Поэтому не используйте EXCEPTION без надобности.

Alter table tab modify column AAA varchar (xxx);

Доброе утро, уважаемые коллеги! Ваша дискуссия безумно интересна, но чисто в академических целях. Мы же людишки мелкие, на земле трудимся, нам более практичныех вопросов обсуждать интересно. А именно. Есть необходимость ограничить текстовое поле по длине. На стороне приложения проверка присутствует. Внимание, вопрос: что дешевле с точки зрения потребления ресурсов и быстрее по скорости: в хранимке тупо обрезать лишнее, или на эти поля повесить CHECK? Особенно с учётом того, что, согласно документации https://postgrespro.ru/docs/postgresql/10/plpgsql-control-structures Наличие секции EXCEPTION значительно увеличивает накладные расходы на вход/выход из блока. Поэтому не используйте EXCEPTION без надобности.

я бы писал check. некоторые ещё бы пользовались varchar(10)

Доброе утро, уважаемые коллеги! Ваша дискуссия безумно интересна, но чисто в академических целях. Мы же людишки мелкие, на земле трудимся, нам более практичныех вопросов обсуждать интересно. А именно. Есть необходимость ограничить текстовое поле по длине. На стороне приложения проверка присутствует. Внимание, вопрос: что дешевле с точки зрения потребления ресурсов и быстрее по скорости: в хранимке тупо обрезать лишнее, или на эти поля повесить CHECK? Особенно с учётом того, что, согласно документации https://postgrespro.ru/docs/postgresql/10/plpgsql-control-structures Наличие секции EXCEPTION значительно увеличивает накладные расходы на вход/выход из блока. Поэтому не используйте EXCEPTION без надобности.

По скорости абсолютно по барабану, ты не там скорость ищешь...

По скорости абсолютно по барабану, ты не там скорость ищешь...

Я везде скорость ищу. Что поделать, трудное детство, деревянные игрушки, прибитые к потолку и снимаемые только на новый год... :)

Зря

По скорости абсолютно по барабану, ты не там скорость ищешь...

Вообще не соглашусь, если проверка на plpgsql, то на каждую строку будет запускаться дополнительная хранимка. А это добавит лишних мс. Вот если бы она была на си, тогда да

По мне правильнее alter столбец в varchar(10) как сказал Дорофей или в хранимке (если только через неё работа с таблицей)

Я везде скорость ищу. Что поделать, трудное детство, деревянные игрушки, прибитые к потолку и снимаемые только на новый год... :)

Как в анекдоте, я ключи потерял.. где? Вон там , у реки... А почему тут ищешь? А там темно все равно!

Вообще не соглашусь, если проверка на plpgsql, то на каждую строку будет запускаться дополнительная хранимка. А это добавит лишних мс. Вот если бы она была на си, тогда да

Она на С

Как в анекдоте, я ключи потерял.. где? Вон там , у реки... А почему тут ищешь? А там темно все равно!

Не, в моем варианте будет: а там я же искал :(

Она на С

Ну если там просто length, то да, ты прав

Доброе утро, уважаемые коллеги! Ваша дискуссия безумно интересна, но чисто в академических целях. Мы же людишки мелкие, на земле трудимся, нам более практичныех вопросов обсуждать интересно. А именно. Есть необходимость ограничить текстовое поле по длине. На стороне приложения проверка присутствует. Внимание, вопрос: что дешевле с точки зрения потребления ресурсов и быстрее по скорости: в хранимке тупо обрезать лишнее, или на эти поля повесить CHECK? Особенно с учётом того, что, согласно документации https://postgrespro.ru/docs/postgresql/10/plpgsql-control-structures Наличие секции EXCEPTION значительно увеличивает накладные расходы на вход/выход из блока. Поэтому не используйте EXCEPTION без надобности.

Короче, резюме - есть возможность сделать alter table - делай так. Нет - вешай check constraint.

ОК, понял, спасибо. Я почему задал вопрос: как-то в памяти отложилось, что varchar(n) - это мягкое ограничение. При необходимости есть возможность выйти за пределы. Глянул доку - таки нет, я с чем-то спутал. Что-то неправильно в голове отложилось. Шарики за ролики заехали. Однако.

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

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

Использование интерпретируемого plpgsql тоже не фонтан

Использование интерпретируемого plpgsql тоже не фонтан

У меня после некоторых экспериментов и объяснений Вани Фролкова существует некоторые сомнения в истинности твоего утверждения.

У меня после некоторых экспериментов и объяснений Вани Фролкова существует некоторые сомнения в истинности твоего утверждения.

Судя по твоим вопросам эксперименты еще должны продолжится ;)

Тех экспериментов нет и неизвестно. Тут более другие и насущные.

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

Никак не влияет

У меня после некоторых экспериментов и объяснений Вани Фролкова существует некоторые сомнения в истинности твоего утверждения.

Очень правомочные сомнения, потому как это неверно

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

А какая нагрузка вообще?

А какая нагрузка вообще?

1. Не могу сказать по причинам, например, разным: крАвавый Ынтрепрайз - такой Ынтерпрайз, и такой крАвавый. 2. Растёт.

Обноволялось виндовс. "Слишком долго" перезагрузили. Посгресс не стартовал.

Я полагал что есть незакрытый транзакционный лог

После этого делаю реиндекс

Как его дальше починить?

Или искать бэкапы?

Почему вы пг 9.6. пытаетесь подсунуть каталог от 9.1 для начала?

Судя по ошибке - таки да, искать бекапы. А вообще в целях самообразования неплохо посмотреть select xmin,xmax,* from <проблемная таблица> where <столбцы индекса> = <проблемное значение>

Почему вы пг 9.6. пытаетесь подсунуть каталог от 9.1 для начала?

Я просто со старых статей случайно скопировал.

Пробую найти эту таблицу в пгадмин2.1

И снова я. На этот раз со свеженьким, относительно, из сообщетсва: http://thebuild.com/blog/2018/03/30/change-this-wal_compression/ Кто-нибудь на отказоустойчивость уже пробовал? Как оно накатывается? Или снова блудом и развратом самому развлекаться?

Поясните, пожалуйста, в чём смысл обсуждения про fsync выше. Из мана по fsync понял, что это способ синхонизации памяти с диском. В postgres fsync применяется где-то?

Поясните, пожалуйста, в чём смысл обсуждения про fsync выше. Из мана по fsync понял, что это способ синхонизации памяти с диском. В postgres fsync применяется где-то?

до чего ж ленивая молодёжь пошла. пожалуйста. https://en.wikipedia.org/wiki/Sync_(Unix)

Поясните, пожалуйста, в чём смысл обсуждения про fsync выше. Из мана по fsync понял, что это способ синхонизации памяти с диском. В postgres fsync применяется где-то?

Вкратце, применяется при записи на диск, и без него durability просто не будет.

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

И какой воркараунд? 1:1 таблицы с нужными полями + Brin index?

Ребят, как лучше всего реализовать поиск с опечатками? Типа при поиске 'Масква' найти 'Москва'

@alexey_kopytov Yaroslav спасибо. Да, всё логично вроде.

А на прямую нельзя разве записать без этих буферов?

Ребят, как лучше всего реализовать поиск с опечатками? Типа при поиске 'Масква' найти 'Москва'

https://postgrespro.ru/docs/postgrespro/10/fuzzystrmatch

Ребят, как лучше всего реализовать поиск с опечатками? Типа при поиске 'Масква' найти 'Москва'

Еще можно сюда посмотреть (F.32.5. Интеграция с текстовым поиском) https://postgrespro.ru/docs/postgresql/10/pgtrgm

Ребят, как лучше всего реализовать поиск с опечатками? Типа при поиске 'Масква' найти 'Москва'

возьми elasticsearch

И снова я. На этот раз со свеженьким, относительно, из сообщетсва: http://thebuild.com/blog/2018/03/30/change-this-wal_compression/ Кто-нибудь на отказоустойчивость уже пробовал? Как оно накатывается? Или снова блудом и развратом самому развлекаться?

А вопрос то в чем?

Господа, подскажите пожалуйста, можно ли эту конструкцию заменить на чтото более пристойное? SELECT name FROM artifacts WHERE release_id = (SELECT id FROM releases WHERE hash LIKE '%' || $1 || '%' OR ref LIKE '%' || $1 || '%' AND project_id IN (SELECT id FROM projects WHERE name LIKE '%' || $2 || '%') limit 1) AND stage_id = (SELECT id FROM stages WHERE name LIKE '%' || $3 || '%' limit 1);

Господа, подскажите пожалуйста, можно ли эту конструкцию заменить на чтото более пристойное? SELECT name FROM artifacts WHERE release_id = (SELECT id FROM releases WHERE hash LIKE '%' || $1 || '%' OR ref LIKE '%' || $1 || '%' AND project_id IN (SELECT id FROM projects WHERE name LIKE '%' || $2 || '%') limit 1) AND stage_id = (SELECT id FROM stages WHERE name LIKE '%' || $3 || '%' limit 1);

CTE повышет пристойность неплохо

CTE повышет пристойность неплохо

Спасибо, убежал читать.

ERROR: S client not available

Господа, подскажите пожалуйста, можно ли эту конструкцию заменить на чтото более пристойное? SELECT name FROM artifacts WHERE release_id = (SELECT id FROM releases WHERE hash LIKE '%' || $1 || '%' OR ref LIKE '%' || $1 || '%' AND project_id IN (SELECT id FROM projects WHERE name LIKE '%' || $2 || '%') limit 1) AND stage_id = (SELECT id FROM stages WHERE name LIKE '%' || $3 || '%' limit 1);

Замените на детерминированный запрос, первым делом: (SELECT id FROM stages WHERE name LIKE '%' || $3 || '%' limit 1); Ну или уберите отсюда LIMIT, если он на самом деле не нужен. А так, JOIN-ы будут выглядеть получше, чем IN-ы, мне кажется.

limit 1 в данном случае просто небольшая гарантия, т.к. всегда должно возвращаться только 1 значение

там конечно есть Unique, но всеже.

limit 1 в данном случае просто небольшая гарантия, т.к. всегда должно возвращаться только 1 значение

А если вернётся не одно, то результат будет случаен, т.е. вы просто ошибку прячете таким образом, нет?

А если вернётся не одно, то результат будет случаен, т.е. вы просто ошибку прячете таким образом, нет?

Чтото типо того

там конечно есть Unique, но всеже.

А как Unique тут поможет, кстати? Например, name = foo, foobar. При LIKE '%foo%' будут выбраны оба.

Тоже вернр

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

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

А что?

А что?

Да, вот ищу правильные варианты реализации

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

а вот как быть с дб встал вопрос

динамическая маршрутизация

динамическая маршрутизация

А с инсертами как поступать, делалать master-master?\

А с инсертами как поступать, делалать master-master?\

В сторонке переносить если надо чтобы другие регионы видели данные других. Или вообще по fdw гулять если такие обращения единичные

Привет. у меня нубский вопрос: возможно ли переустановить postgresql на сервере без потери данных? у меня есть тейблспейс для данных. бэкап не могу сделать ибо не работают инструменты после починки жд(видимо потерлись файлы для работы постгри)

Привет. у меня нубский вопрос: возможно ли переустановить postgresql на сервере без потери данных? у меня есть тейблспейс для данных. бэкап не могу сделать ибо не работают инструменты после починки жд(видимо потерлись файлы для работы постгри)

Ну бэкап можно сделать просто скопировав все файлы, предварительно остановив постгрес

Ну бэкап можно сделать просто скопировав все файлы, предварительно остановив постгрес

Т. Е просто тейблспейс скопировать и все?)

подскажите, в 10 postgres есть merge into?

подскажите, в 10 postgres есть merge into?

Нет.

Нет.

обещали же еще в 9 сделать))

Есть INSERT INTO ... ON CONFLICT. Может, подойдёт?

Т. Е просто тейблспейс скопировать и все?)

не просто, все файлы 9,х/data нужно, в т.ч. и сам тейблспейс, если он в другом месте. условно говоря вы слепок файлов делаете вручную

Есть INSERT INTO ... ON CONFLICT. Может, подойдёт?

попробую, спасибо)

но по идее постгрес ничего побить не должен

А с инсертами как поступать, делалать master-master?\

Я не понял ваш вопрос и неправильно дал ответ. Вам надо к архитектору обратиться лучше. Но, как бы, мать природу не обманишь

не просто, все файлы 9,х/data нужно, в т.ч. и сам тейблспейс, если он в другом месте. условно говоря вы слепок файлов делаете вручную

Хм у меня нет директории data. Завтра буду дальше курить. Большое спасибо

Хм у меня нет директории data. Завтра буду дальше курить. Большое спасибо

9.*/main?

9.*/main?

Да

Да

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

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