если джоины идут друг за другом то джоин происходит по результатам предыдущего джоина? ` LEFT JOIN "zones" ON "zones"."organization_id" = "user_organizations"."organization_id" LEFT JOIN "groups" ON "groups"."organization_id" = "zones"."organization_id" ` Вот группы приджонятся относительно выбранных зон или относительно всей таблицы зон?

JOIN-ы всегда идут парами. В смысле, у них всегда два аргумента. Т.е. a JOIN b JOIN c JOIN d -> ((a JOIN b) JOIN c) JOIN d

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

двух_слов

Спасибо за ответ) Ща сформулирую другой вопрос. мне то в итоге нужно джоинить относительно предыдущего джоина

snake_case

Привет! Новая встреча #RuPostgres пройдёт уже в эту субботу, 15 сентября. У нас немного расширилась программа, и остаётся ещё несколько свободных мест для слушателей. А ещё мои коллеги сделали мини-викторину, посвященную Postgres. Она проходит онлайн: присоединяйтесь, мы разыгрываем несколько призов. Все подробности тут: https://habr.com/company/avito/blog/422841/

во множественном

а как JOIN в скобки то заворачивать

В единственном, кроме пересечений по ключевым словам. Поэтому users как правило во множественном.

Друзья, как заставить initdb разговаривать по-английски? Эта падла игнорирует все опции

> initdb.exe --lc-messages=English_Australia.1252 initdb: каталог данных не определён.

а каталог данных определить не помогает? --pgdata="/foo/bar/"

Друзья, как заставить initdb разговаривать по-английски? Эта падла игнорирует все опции

Наверное, системную локаль надо менять

Наверное, системную локаль надо менять

Можно как-то через SET?

Можно как-то через SET?

на windows не знаю)

> initdb.exe --lc-messages=English_Australia.1252 initdb: каталог данных не определён.

LC_MESSAGES="C" initdb ...

Или POSIX вместо C

SET LC_MESSAGES=English_Australia.1252 сработало

LC_MESSAGES="C" initdb ...

SET LC_MESSAGES=C тоже сработало. Сенкс!

Друзья, как заставить initdb разговаривать по-английски? Эта падла игнорирует все опции

Вот так можно ещё: apt-get install -y postgresql-common sed -i "s@#initdb_options = ''@initdb_options = '--encoding=UTF8 --data-checksums --locale=en_US.UTF-8'@g" /etc/postgresql-common/createcluster.conf apt-get install -y postgresql-10

нене, мне только вывод самой утилиты

stdout ee

А то нихрена порой не понятно, что присылают

Допустим, но я всё равно не понимаю, как вот это может быть "тонкостью" или "типичным рабочим моментом" (и зачем вообще это знать ;) ): > Как вычислить количество ЗАГЛАВНЫХ (английских) букв в строке с помощью SQL? > Как посчитать сумму чисел (не цифр) в строке с помощью SQL То же самое касается вопроса номер 13. Мало того, что он сформулирован нечётко (может быть несколько исходов, включая неожиданные), но и, опять-таки, зачем это знать?

В обоих случаях regexp )

а как JOIN в скобки то заворачивать

С помощью скобок, внезапно. ;) Но обычно это просто не нужно.

В обоих случаях regexp )

То есть, та или другая задача у кого-то является "типичным рабочим моментом"? ;)

Татьяна Снапкова будет жить. Поприветствуем!

То есть, та или другая задача у кого-то является "типичным рабочим моментом"? ;)

первая является типовой задачей для людей, которые пытаются разруливать асинхронку не на уровне очередей, а на уровне БД а вторая для меня была типовой, когда я длительное время работал с легаси табличкой, где контактные данные были представлены ввиде текстовой строки, где содержались телефоны, местные, городские сотовые, фИО в разных вариацияю мыла и прочие прелести, и мне надо было привести все в формат json )

первая является типовой задачей для людей, которые пытаются разруливать асинхронку не на уровне очередей, а на уровне БД а вторая для меня была типовой, когда я длительное время работал с легаси табличкой, где контактные данные были представлены ввиде текстовой строки, где содержались телефоны, местные, городские сотовые, фИО в разных вариацияю мыла и прочие прелести, и мне надо было привести все в формат json )

> первая является типовой задачей для людей, которые пытаются разруливать асинхронку не на уровне очередей, а на уровне БД Так для этого есть и типовые же решения (и, скорее всего, "шаг вправо, шаг влево" — и решение уже не работает). > и мне надо было привести все в формат json ) Т.е. одномоментно, транзакционно, огромный объём? Потому что если что-то из этого не так, Вы просто использовали не лучший инструмент / инструмент не по назначению (извините за резкость). :(

> первая является типовой задачей для людей, которые пытаются разруливать асинхронку не на уровне очередей, а на уровне БД Так для этого есть и типовые же решения (и, скорее всего, "шаг вправо, шаг влево" — и решение уже не работает). > и мне надо было привести все в формат json ) Т.е. одномоментно, транзакционно, огромный объём? Потому что если что-то из этого не так, Вы просто использовали не лучший инструмент / инструмент не по назначению (извините за резкость). :(

разовая операция в рамках рефакторинга

это я про второе

https://otus.ru/events/subd_open/136/?utm_source=telegram&utm_medium=cpm&utm_campaign=subd&utm_content=lesson&utm_term=SysadminNotes

как сделать выборку всех столбцов из таблицы и 1 столбец указать по другому назвать?

select col as myName from table?)

как сделать выборку всех столбцов из таблицы и 1 столбец указать по другому назвать?

"SELECT <перечисляете все другие поля>, поле AS дгугое_название FROM ..." Другого способа нет.

как сделать выборку всех столбцов из таблицы и 1 столбец указать по другому назвать?

ну если нет разницы будет ли лишнее поле, то можно и select *, pole as newname from ...

если перечислять лень

Всё равно в procuction "*" использовать не надо, а если это какие-то одноразовые запросы, лучше, наверное, найти какой-то инструмент (редактор), который будет просто вставлять список полей.

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

ну если нет разницы будет ли лишнее поле, то можно и select *, pole as newname from ...

супер, тоесть можно SELECT * и потом указать 1 поле для изменения названия?

ну там в ответе будет и оригинальное название тоже, но и новое

ой ну эт паршиво

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

pg 9.6 debian, 393 соединения

ой ну эт паршиво

А Вам зачем?

всегда можно упороться по жести и сгенерить sql select row_number() over(), * from information_schema.columns where table_schema = 'public' and table_name = 'table'

и выполнить его в do блоке))

тогда другой вопрос, мне надо что бы в код залетело название в кемел кейсе типа currentFrequency, вместо current_frequency

очень сложно

нормальная ли практика сразу в базу писать стоглбец в кемел кейсе?))

тогда другой вопрос, мне надо что бы в код залетело название в кемел кейсе типа currentFrequency, вместо current_frequency

тогда просто каждое поле переназвать

только пг регистро нечувствителен

в ответе будет с маленькой буквы всё

pg 9.6 debian, 393 соединения

А ну крутоваты настройки-то? У Вас действительно есть [как минимум] 512 Гигабайт памяти, если что?

так что на стороне клиента если только

А ну крутоваты настройки-то? У Вас действительно есть [как минимум] 512 Гигабайт памяти, если что?

48Гб всего, но по факту активных запросов мало

select 'select '|| array_to_string(array_agg( case when row_number = 1 then column_name ||' as new_name' else column_name end), ', ') || ' from demo_range' from ( select row_number() over(), column_name from information_schema.columns where table_schema = 'public' and table_name = 'demo_range' ) t

количество соединений большое из за использования в фоновых обработчиков LISTEN NOTIFY

и OS не упирается в память, в своп не лезет

и OS не упирается в память, в своп не лезет

А OOM тогда откуда? Какая версия PostgreSQL? А сколько примерно активных запросов, по факту?

pg 9.6 debian, 393 соединения

пулер соединений используете?

9.6 примерно по 10 активных запросов

пулер не используем, много баз в кластере (175).

количество соединений большое из за использования в фоновых обработчиков LISTEN NOTIFY

Здравствуйте. Зачем для обработки NOTIFY большое количество соединений?

Здравствуйте. Зачем для обработки NOTIFY большое количество соединений?

на каждую базу по несколько обработчиков очередей (от двух до 4) которые слушают свои события на LISTEN

на каждую базу по несколько обработчиков очередей (от двух до 4) которые слушают свои события на LISTEN

На каждую БД достаточно 1-го слушателя различных каналов. Плюс по каждому каналу можно передавать payload (около 8 кб).

я не могу понять, почему сейчас htop показывает свободно 19Gb, а в логах OOM

срочный запрос

у меня LANGUAGE plpgsql как в sikuel_zapros вставить переменнки FOR elem IN EXECUTE sikuel_zapros LOOP END LOOP

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

переменки из секции DECLARE

9.6 примерно по 10 активных запросов

Точная версия какая? 9.6.что?

9.6.9

я не могу понять, почему сейчас htop показывает свободно 19Gb, а в логах OOM

А Вы знаете, какой именно запрос вызывает эту ошибку?

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

А Вы знаете, какой именно запрос вызывает эту ошибку?

ОШИБКА: загрузить библиотеку "/usr/lib/postgresql/9.6/lib/hstore.so" не удалось: /usr/lib/postgresql/9.6/lib/hstore.so: сбой отображения сегмента из разделяемого объекта: Невозможно выделить память

есть и такие сообщения

из расширений включен stat_statements

а СУБД случаем не в докере?

нет

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

к слову, пробовал снизить work_mem и это не помогало

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

А можно по подробней, как вы это видите?

А можно по подробней, как вы это видите?

1 слушатель на много каналов. Всё тривиально.

1 слушатель на много каналов. Всё тривиально.

Ну это понятно, что слушать можно много чего. Вы что-то там про очередь писали

я не могу понять, почему сейчас htop показывает свободно 19Gb, а в логах OOM

Ну это сейчас, а мониторинг у Вас есть? Может, это какие-то "мгновенные" пики (возможно, даже не из-за PostgreSQL)?

Ну это понятно, что слушать можно много чего. Вы что-то там про очередь писали

Я писал про очередь уведомлений. А в чём вопрос?

Ну это сейчас, а мониторинг у Вас есть? Может, это какие-то "мгновенные" пики (возможно, даже не из-за PostgreSQL)?

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