иначе он 3 поля засасывает

Что-что? > мне нужна только последняя анкета По какому принципу "последняя"?

ну вот ордер бай деск по айди

из тех анкет, что принадлежат юзеру

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

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

Если устраивает, почему Вы его не пишите, а пишете сортировку по user_id анкеты?!

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

Может быть, Вам было нужно что-то вроде: SELECT da.user_id, da."text", da.id, da.created_at, last_form.name FROM discussions_answers AS da LEFT JOIN LATERAL ( SELECT uf.name FROM user_forms AS uf WHERE uf.user_id = da.user_id ORDER BY uf.id DESC LIMIT 1 ) AS last_form ON true WHERE da.status = 1 ORDER BY da.id;

сейчас прогоню, секунду

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

Вообще не бывает абстрактно последних записей. Без задания порядка сортировки это бессмысленное понятие. ;)

работает, спасибо

я не могу понять, где у меня ошибка?

в алиасе?

он не должен совпадать с тем, что as внутри ?

я не могу понять, где у меня ошибка?

У Вас их вообще-то, как минимум, две (или три). ;) > он не должен совпадать с тем, что as внутри ? Может и совпадать. Очень помогает запутаться, если Вам это нужно. :( В приниципе, "снаружи" подзапроса не видно то, что внутри него. И, обычно, внутри не видно то, что снаружи, но LATERAL меняет это поведение на обратное (т.е. все alias-ы до этого FROM item (подзапроса) становятся видны в нём).

Но это нужно, чтобы отдать туда WHERE да?

Я так понял

Но это нужно, чтобы отдать туда WHERE да?

Что "это"? Alias, LATERAL, название? Вы можете выражаться конкретнее? Мне, может, тоже лень печатать. ;)

Простите, я не специально, я по глупости ) Латерал нужен, чтобы прокидывать внутрь алиасы, чтобы указывать при дополнительном запросе связь*

SELECT da.user_id, da."text", da.id, da.created_at, last_form.name FROM discussions_answers AS da LEFT JOIN LATERAL ( SELECT uf.name FROM user_forms AS uf WHERE uf.user_id = da.user_id ORDER BY uf.id DESC LIMIT 1 ) AS last_form ON true WHERE da.status = 1 AND da.discussions_id = 38 ORDER BY da.id;

я добавил ещё одно условие

этот код работает

но он правильный? так и надо указывать?

WHERE da.status = 1 AND da.discussions_id = 38

Простите, я не специально, я по глупости ) Латерал нужен, чтобы прокидывать внутрь алиасы, чтобы указывать при дополнительном запросе связь*

Всё, что делает LATERAL — обеспечивает видимость предыдущих элементов FROM в данном подзапросе (который стоит справа от LATERAL). Попробуйте его убрать — увидите, что будет.

но он правильный? так и надо указывать?

Вообще, Вам виднее... но что Вас смущает? (Так Вы для всех записей discussions_answers, для которых da.status = 1 AND da.discussions_id = 38, выбираете последнюю (по user_forms.id) запись user_forms.)

Ну вот да, пишет, что он не понимает "da" и Латерал нужен для того, чтобы видел discussions_answers AS da и тем самым читаемость кода была

Вообще, Вам виднее... но что Вас смущает? (Так Вы для всех записей discussions_answers, для которых da.status = 1 AND da.discussions_id = 38, выбираете последнюю (по user_forms.id) запись user_forms.)

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

спасибо

Ну вот да, пишет, что он не понимает "da" и Латерал нужен для того, чтобы видел discussions_answers AS da и тем самым читаемость кода была

Без LATERAL он вообще не увидит discussions_answers, как её не назовите.

Без LATERAL он вообще не увидит discussions_answers, как её не назовите.

а, хорошо, понял, спасибо

а, хорошо, понял, спасибо

И по поводу alias-а: технически, подзапрос можно было назвать user_forms, без проблем. Но вот Вы так и поступили... и тут же запутались. ;) Так что это плохой стиль, я считаю.

Да, я теперь понимаю.

Сейчас вывод рубрик буду делать, надеюсь не придётся возвращаться.

А какие best practices есть для написания pg расширения над сишной функцией принимающей int с битовыми флажками?

Констант в sql вроде нет, писать функцию парсящую строку с названием флага в int?

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

подскажите, а постгре поддерживает многопоточность?

Если неправильно выразился, сильно не пинайте ?

версия 10.3

А какие best practices есть для написания pg расширения над сишной функцией принимающей int с битовыми флажками?

Можете пример привести того, что вы имеете в виду? Вопрос не совсем понятен. В pg есть битовые операторы. Констант нет, можно создавать IMMUTABLE SQL функции, как вариант.

подскажите, а постгре поддерживает многопоточность?

Нет. В любой версии.

Нет. В любой версии.

Печаль ? Спасибо!

подскажите, а постгре поддерживает многопоточность?

Вы точно про многопоточность хотите знать? А может про распараллеливание запросов? Если второе, то оно с 9.6 вполне себе есть.

Печаль ? Спасибо!

А Вам зачем / почему это вообще может быть важно? Это сугубо внутреннее дело сервера, нет?

А Вам зачем / почему это вообще может быть важно? Это сугубо внутреннее дело сервера, нет?

чтобы быстрее работало, не?

чтобы быстрее работало, не?

Ну точно, распараллеливание запросов. Есть такое.

чтобы быстрее работало, не?

Никакой связи тут нет, не?

Никакой связи тут нет, не?

обрабатывать 10 запросов поочередно, или параллельно?

обрабатывать 10 запросов поочередно, или параллельно?

Это как вы приложение напишите.

обрабатывать 10 запросов поочередно, или параллельно?

Так они и так параллельно обрабатываютя, причём тут многопоточность? Вы что, всерьёз думали, что PostgreSQL обрабатывает запросы от разных клиентов строго последовательно?!

Если неправильно выразился, сильно не пинайте ?

поэтому и уточнил

Так они и так параллельно обрабатываютя, причём тут многопоточность? Вы что, всерьёз думали, что PostgreSQL обрабатывает запросы от разных клиентов строго последовательно?!

Это было бу удобно! И никаких уровней изоляций и MVCC придумывать было бы не нужно )

Это было бу удобно! И никаких уровней изоляций и MVCC придумывать было бы не нужно )

sqlite ждёт Вас! Хотя даже там уже есть режим "один писатель + много читателей"... ;(

Так они и так параллельно обрабатываютя, причём тут многопоточность? Вы что, всерьёз думали, что PostgreSQL обрабатывает запросы от разных клиентов строго последовательно?!

В общем, имеет смысл увеличивать число ядер, для ускорения обработки в связке 1С/postgresql/ubuntu?

В общем, имеет смысл увеличивать число ядер, для ускорения обработки в связке 1С/postgresql/ubuntu?

Да, конечно. Не факт, что это то, на что нужно начинать тратить деньги в первую очередь в Вашем случае, естественно (по ситуации смотрите).

Да, конечно. Не факт, что это то, на что нужно начинать тратить деньги в первую очередь в Вашем случае, естественно (по ситуации смотрите).

Все понятно, спасибо! ?

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

пишут что возможно, даже по дороге обновляя мажорную версию — порядок примерно такой может быть: https://blog.2ndquadrant.com/upgrading-to-postgresql-11-with-logical-replication/

пишут что возможно, даже по дороге обновляя мажорную версию — порядок примерно такой может быть: https://blog.2ndquadrant.com/upgrading-to-postgresql-11-with-logical-replication/

Я по-моему читал уже, и это вроде не то

Там нет переезда мастера на слейв и обратно Там просто про обновление без даунтайма

Там нет переезда мастера на слейв и обратно Там просто про обновление без даунтайма

Ну так в логической репликации и нет одного master-а и slave-а — Вы там можете что угодно намешать. :) Т.е. обычно рассматриваемые примеры (в т.ч. в документации, как мне помнится) касаются только тривиального случая.

А есть какие-либо рабочие кейсы у кого-нибудь с переездом логической репликации?

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

Господа, прошу источников, где была бы скомпилирована инфа по постгресу, со всеми quirks, так сказать + возможно какая то информация по особенностям внутренней реализации (отличие от mysql, MSSql Oracle и т.п.) Спасибо

Можете пример привести того, что вы имеете в виду? Вопрос не совсем понятен. В pg есть битовые операторы. Констант нет, можно создавать IMMUTABLE SQL функции, как вариант.

В С я передаю в функцию MYFLAG_FOO||MYFLAG_BAR. Каким способом лучше всего рнализовать это в sql?

Ну так в логической репликации и нет одного master-а и slave-а — Вы там можете что угодно намешать. :) Т.е. обычно рассматриваемые примеры (в т.ч. в документации, как мне помнится) касаются только тривиального случая.

хм, может тогда есть какие-то другие кейсы для репликации потаблично?

Господа, прошу источников, где была бы скомпилирована инфа по постгресу, со всеми quirks, так сказать + возможно какая то информация по особенностям внутренней реализации (отличие от mysql, MSSql Oracle и т.п.) Спасибо

https://www.postgresql.org/docs/current/static/index.html ;) А если серьёзно, что Вас конкретно интересует?

В С я передаю в функцию MYFLAG_FOO||MYFLAG_BAR. Каким способом лучше всего рнализовать это в sql?

SELECT myfunc(4 /* MYFLAG_FOO */ || 64 /* MYFLAG_BAR */);?

хм, может тогда есть какие-то другие кейсы для репликации потаблично?

Можно более-менее использовать для DWH, например. А Вам вообще зачем? Ищете, куда бы применить?

Можно более-менее использовать для DWH, например. А Вам вообще зачем? Ищете, куда бы применить?

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

https://www.postgresql.org/docs/current/static/index.html ;) А если серьёзно, что Вас конкретно интересует?

преследую дву вещи 1) освежить необходимую инфу к собеседованию 2) посмотреть фишки внутренней реализации (почему постгрес, а не другая RMDB)

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

Я не понял, зачем Вам что-то ломать и выделять... Чем Вам не подходит обычная physical streaming replication?

SELECT myfunc(4 /* MYFLAG_FOO */ || 64 /* MYFLAG_BAR */);?

Не очень. И что если api изменится. myfunc_flag("FOO") || myfunc_flag("BAR") не практикуется? Других вариантов нет?

Я не понял, зачем Вам что-то ломать и выделять... Чем Вам не подходит обычная physical streaming replication?

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

Не очень. И что если api изменится. myfunc_flag("FOO") || myfunc_flag("BAR") не практикуется? Других вариантов нет?

create function MYFLAG_FOO() as $$ SELECT 4; $$ language SQL IMMUTABLE;

О, вот это похоже то что надо, спасибо

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

> ну настолько я вычитал из доки, стриминг захватывает вообще весь инстанс постгреса Да, без вариантов (не считая unlogged tables). > , а в этом инстансе есть таблички, банально с сессиями хотя бы, их реплицировать не надо, Почему не надо? Это очень странно, я бы уже задумался, что здесь что-то не так. Причина задуматься следующая: переключение на реплику почти ничем не отличается от ситуации, когда у Вас master внезапно упал и тут же поднялся (recovery). Если Ваше приложение этого не переносит... это что-то нехорошее, нет? > так как по требованием есть ситуация, когда мы можем подключиться к реплике и сказать ей, что отныне ты становишься мастером, и это из приложения происходит, физического доступа к консоли нет По каким требованиям? Почему бы не обеспечить переключение одним из обычных способов?

> ну настолько я вычитал из доки, стриминг захватывает вообще весь инстанс постгреса Да, без вариантов (не считая unlogged tables). > , а в этом инстансе есть таблички, банально с сессиями хотя бы, их реплицировать не надо, Почему не надо? Это очень странно, я бы уже задумался, что здесь что-то не так. Причина задуматься следующая: переключение на реплику почти ничем не отличается от ситуации, когда у Вас master внезапно упал и тут же поднялся (recovery). Если Ваше приложение этого не переносит... это что-то нехорошее, нет? > так как по требованием есть ситуация, когда мы можем подключиться к реплике и сказать ей, что отныне ты становишься мастером, и это из приложения происходит, физического доступа к консоли нет По каким требованиям? Почему бы не обеспечить переключение одним из обычных способов?

дело в том, что это инстанс конфигурации ядра системы, конфигурация меняется довольно нечасто, ну может раз в неделю кто-то что-то делает, система в принципе может жить и без этого центра конфигурации самостоятельно просто этот центр конфигурации потом накатывает конфигурацию на систему и система в зависимости от применненных настроек живет, 100% аптайм центра конфигурации необязателен я поэтому сразу и сказал, что это просто горячий бекап, допустим центр конфигурации был вне самой системы несколько дней и сдох, тогда система просто пойдет на следующий резервный центр и так по кругу, соответственно все реплики просто должны автоматом переключаться на новый мастер так же есть кейс, когда админ сам подключается к какому-нибудь резервному и говорит от его имени всей системе, что я теперь мастер, все подключайтесь ко мне (ну допустим текущий мастер идет на обслуживание) как это организовать на потоковой репликации кроме как выноса конкретных таблиц с конфигурацией в отдельный инстанс я не знаю, но это не хотелось бы делать, ибо еще один инстанс, еще одно звено в цепочке

Как можно на postgreS 10 установить дополнительные библиотеки shared_preload_libraries на CentOs7 ???

Привет всем! Подскажите как составить запрос: Есть таблицы provider и application, связь один провайдер — много аппликейшенов. У аппликейшена есть поле created_at Необходимо узнать есть ли у провайдера апликейшены за последние 90 дней. Можно ссылкой в меня кинуть куда посмотреть, что прочитать. Заранее спасибо за помощь!)

Все с теми же данными вопрос, помогите достать провайдеров дата создания ПОСЛЕДНЕЙ заявки которых(провайдеров) попадает в определенный диапазон

Привет всем! Подскажите как составить запрос: Есть таблицы provider и application, связь один провайдер — много аппликейшенов. У аппликейшена есть поле created_at Необходимо узнать есть ли у провайдера апликейшены за последние 90 дней. Можно ссылкой в меня кинуть куда посмотреть, что прочитать. Заранее спасибо за помощь!)

https://www.postgresql.org/docs/10/static/functions-subquery.html#FUNCTIONS-SUBQUERY-EXISTS

> допустим центр конфигурации был вне самой системы несколько дней и сдох, тогда система просто пойдет на следующий резервный центр и так по кругу, соответственно все реплики просто должны автоматом переключаться на новый мастер А у Вас это всё уже работает? Особенно, automatic failover? С логической репликацией Вам это тоже всё придётся сделать, причём, скорее всего, самим. И с другими её проблемами как-то справиться (DDL и т.п.), если они вас касаются. > но это не хотелось бы делать, ибо еще один инстанс, еще одно звено в цепочке Но, тем не менее, с streaming replication другого способа в самом деле нет...

> А у Вас это всё уже работает? Особенно, automatic failover? уху, система в принципе готова к внезапному переезду ЦУ, вопрос только как отреплицировать данные корректно и еще бОльший вопрос, как переключать мастер

Все с теми же данными вопрос, помогите достать провайдеров дата создания ПОСЛЕДНЕЙ заявки которых(провайдеров) попадает в определенный диапазон

Так тоже самое примерно...

Ща гляну, спасибо

> А у Вас это всё уже работает? Особенно, automatic failover? уху, система в принципе готова к внезапному переезду ЦУ, вопрос только как отреплицировать данные корректно и еще бОльший вопрос, как переключать мастер

Так эти вопросы ("как отреплицировать данные корректно" и "как переключать мастер") и есть основные, остальное, обычно, мелочи. ;)

Так эти вопросы ("как отреплицировать данные корректно" и "как переключать мастер") и есть основные, остальное, обычно, мелочи. ;)

совет один, переходить на потоковую репликацию?

совет один, переходить на потоковую репликацию?

А там у Вас эти вопросы уже решены? ;) Я только к тому, что Вы никуда от этого не денетесь, в любом случае.

А там у Вас эти вопросы уже решены? ;) Я только к тому, что Вы никуда от этого не денетесь, в любом случае.

ну с точки зрения приложения - да с точки зрения постгреса, еще никто не смотрел толком

ну с точки зрения приложения - да с точки зрения постгреса, еще никто не смотрел толком

> дело в том, что это инстанс конфигурации ядра системы Я чего-то не понял, всё же. Так это отдельные серверы / instances?

> дело в том, что это инстанс конфигурации ядра системы Я чего-то не понял, всё же. Так это отдельные серверы / instances?

и? я не улавливаю мысль

> дело в том, что это инстанс конфигурации ядра системы Я чего-то не понял, всё же. Так это отдельные серверы / instances?

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

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

Ну а так почему не потоковая репликация этих instance/серверов, они же у Вас уже есть?

Ну а так почему не потоковая репликация этих instance/серверов, они же у Вас уже есть?

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

> архитектура становится сложная, в этом инстансе куча БД Которые все "умрут" одновременно, если что, разве нет? Что-то Вы там переусложнённое делаете, судя по описанию. ;)

> архитектура становится сложная, в этом инстансе куча БД Которые все "умрут" одновременно, если что, разве нет? Что-то Вы там переусложнённое делаете, судя по описанию. ;)

ну есть бекапы)

> архитектура становится сложная, в этом инстансе куча БД Которые все "умрут" одновременно, если что, разве нет? Что-то Вы там переусложнённое делаете, судя по описанию. ;)

да нет, все просто, есть БД, ее надо отреплицировать в кучу слевов, причем один из слейвов может стать (и станет когда-нибудь) новым мастером, при этом на аптайм пофигу, и реплицировать надо не все таблицы =)

да нет, все просто, есть БД, ее надо отреплицировать в кучу слевов, причем один из слейвов может стать (и станет когда-нибудь) новым мастером, при этом на аптайм пофигу, и реплицировать надо не все таблицы =)

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