@pgsql
Mikhail24.01.2018
15:19:46
15:19:46
Во. Ещё один параметр появился. Ещё один подкину:
server_idle_timeout
Ну чтобы скучно не было.
Это точно не о том, там соединение нагруженное былоЭтот параметр один из крайне полезных! Но он конечно же не рвёт соединение в момент его использования !!!
Может он и не рвёт, но кто то рвёт :)
Mikhail24.01.2018
15:20:34
15:20:34
Что такое _нагруженное_ ?!
Я вас просил показать как и что вы воспроизводите ?!
Google
Maksim24.01.2018
15:21:55
15:21:55
а сруза после, если прошел таймаут
Вы написали, что циклические insert (как я понял, в транзакциях один insert) на клиенте рвутся. Т.е. клиентское соединение не перекидывается прозрачно на другой коннект пула?Yaroslav24.01.2018
15:23:05
15:23:05
Одно дело - когда клиент пытается приконнектится к базе и у него это не получается за заданный таймаут. Тогда работать с базой нельзя. Другое дело, когда он посылает запрос и получает ответ не через 0.1msec, а через 10msec. Ну или даже секунду.
Проблема в том, что пока есть активные клиенты и их число больше чем ограничение на число сессий, то нового просто не пустят. Даже если клиенты тупо рвут коннекшины после каждого стайтмента, всё равно нет никакой гарантии, что клиенту удасться установтить соединение с сервером за N попыток с некторым таймаутом.
Один таймаут: "Одно дело - когда клиент пытается приконнектится к базе и у него это не получается за заданный таймаут."
Второй таймаут: "Другое дело, когда он посылает запрос и получает ответ не через 0.1msec, а через 10msec. Ну или даже секунду."
Чем один "краше" другого? Почему в первом случае работать с базой нельзя?
А во втором случае эта ситуация (нет свободного соединения) для приложения выглядеть как session/query timeout, и оно точно так же будет считать соединение "мёртвым", нет?Mikhail24.01.2018
15:24:29
15:24:29
Sergey24.01.2018
15:24:40
15:24:40
Один таймаут: "Одно дело - когда клиент пытается приконнектится к базе и у него это не получается за заданный таймаут."
Второй таймаут: "Другое дело, когда он посылает запрос и получает ответ не через 0.1msec, а через 10msec. Ну или даже секунду."
Чем один "краше" другого? Почему в первом случае работать с базой нельзя?
А во втором случае эта ситуация (нет свободного соединения) для приложения выглядеть как session/query timeout, и оно точно так же будет считать соединение "мёртвым", нет?
Потому что аналитический запрос на 1-2-5-12 часов эт нормально. А > 2 секунд на login уже как-то многоватоMikhail24.01.2018
15:25:19
15:25:19
Maksim24.01.2018
15:26:13
15:26:13
Я выше писал как можно воспроизвести
приведите лучше весь скрипт с настройками баунсера, если не сложноYaroslav24.01.2018
15:26:32
15:26:32
Mikhail24.01.2018
15:26:36
15:26:36
Если бы я мог, давно бы сделал :)
Mikhail24.01.2018
15:28:52
15:28:52
Mikhail24.01.2018
15:29:34
15:29:34
А к чему, если после смены типа пулинга проблема ушла?
Mikhail24.01.2018
15:29:36
15:29:36
Это какая-то ваша частная проблема с приложением и/или настройками tcp
Mikhail24.01.2018
15:29:47
15:29:47
GoogleMikhail24.01.2018
15:30:11
15:30:11
Иначе смена пулинга не помогла бы
Mikhail24.01.2018
15:30:14
15:30:14
А к чему, если после смены типа пулинга проблема ушла?
Так как вы ничего не можете показать , то и обсуждать нечегоMikhail24.01.2018
15:30:35
15:30:35
Ну хорошо :)
Taras ?24.01.2018
20:49:58
20:49:58
добровечер, подскажите-помогите пожалуйста с маленьким вопросом
у меня в таблице имеется
"params" integer[] ,
в записях встречается, к примеру,
{1,2,7}
{2,9,3}
{3,5,1}
{2,5,13}
как мне достать все записи, где в поле params встречается 3?
... WHERE ?
Denis24.01.2018
20:51:04
20:51:04
params @> ARRAY[3]
https://www.postgresql.org/docs/9.6/static/functions-array.html
Taras ?24.01.2018
20:52:53
20:52:53
благодарю
понял, похоже как и с ltree
Alex24.01.2018
21:00:41
21:00:41
добровечер, подскажите-помогите пожалуйста с маленьким вопросом
у меня в таблице имеется
"params" integer[] ,
в записях встречается, к примеру,
{1,2,7}
{2,9,3}
{3,5,1}
{2,5,13}
как мне достать все записи, где в поле params встречается 3?
... WHERE ?
https://www.postgresql.org/docs/10/static/intarray.htmlМожет будет быстрее
KizzarU24.01.2018
22:40:26
22:40:26
Лучший новостной-инсайдерский канал в Telegram!
? https://t.me/SharkCIA
Там Вы найдете:
? Ежедневный поток полезной информации.
? Аналитические статьи.
? Интересные факты.
? И многое другое!
? Целый путеводитель к успеху в вашем телефоне.
▪️Присоединяйся к каналу:
▪️https://t.me/SharkCIA
Междоус25.01.2018
07:49:41
07:49:41
Всем привет. У нас pg 9.6.
Предисловие:
До вчера работала стриминговая репликация нормально. Но сломались индексы groonga на мастере(реально не нашли причин) и в таком виде они переехали на слейв. На мастере ингдексы вылечили удалением файлов индекса и переиндексацией. На слейве было все также плохо.
Проблема:
Переделали реплику. Удалили старую, создали заново. Норм всё. Но почему-то на слейве у всех счетчиков значение больше на 32 чем на мастере. Как лечить?
Ну или куда смотреть?
Yaroslav25.01.2018
08:22:00
08:22:00
Междоус25.01.2018
08:22:35
08:22:35
А какая Вам разница? Всё равно slave read-only, нет?
Да. И у нас счетчиков много и от них зависят данные. Выборки не работают, не то возвращают и в таком духеGoogleYaroslav25.01.2018
08:22:54
08:22:54
у нас берется last_value от сиквенса
Зачем? И да, если у Вас что-то важное от этого зависит —- это ошибка дизайна. :(
const25.01.2018
08:23:40
08:23:40
Зачем? И да, если у Вас что-то важное от этого зависит —- это ошибка дизайна. :(
чтобы не тащить из БД кучу данных, которые ограничены только сверху, мы решили ограничить их еще и снизу, берем last_value от счетчика - 100Междоус25.01.2018
08:25:37
08:25:37
Зачем? И да, если у Вас что-то важное от этого зависит —- это ошибка дизайна. :(
Про дизайн: Как делать последовательность значений, чтобы не повторялось значение в куче асинхронных/разнесенных обработчиков? БД это делает легко. Засунули значение, инкременгт счетчика, RETURNING *
Arthur25.01.2018
08:34:11
08:34:11
sequence. которые самые обычные
Вот тут есть небольшое пояснение
https://www.postgresql.org/message-id/CA%2BU5nMLrdpv2oAY6%2BV0nCugwfFg%2BXFucdk1OZGZOgViCb3%2BkKg%40mail.gmail.comМеждоус25.01.2018
08:35:03
08:35:03
Жесть какая там написана ?
Subb9825.01.2018
08:41:25
08:41:25
Добрый день. Я почти закончил реализацию фичи по получению новых тем для каждого пользователя. Вот запрос на чистом SQL: http://rextester.com/XTMQV15104 Вопрос у меня следующий. Представим, что у нас накопилось 33000 тем (topics) и зарегистрировалось 17500 пользователей (users). Следовательно, в таблице participants при таких числах может быть 577 500 000 записей. Вопрос в том, насколько это хреновое решение и насколько оно будет медленно работать?
При относительно небольшом кол-ве тем / пользователей мы получим огромное кол-во записей в таблице m2m. Можно ли как-то это оптимизировать?
Lev25.01.2018
09:03:14
09:03:14
почему бы не хранить просто дату создания/обновления темы и дату последнего просмотра пользователя. И возвращать все темы новее даты конкретного пользователя?
Subb9825.01.2018
09:05:11
09:05:11
Так и есть. Но дату просмотра этой темы нужно хранить для каждого конкретного пользователя.
Вот и получается, что, например, имея 2 темы и 2 пользователей, мы получаем уже 4 записи.
Смотрю сейчас таблицу для phpBB, там то же самое. -_-
https://wiki.phpbb.com/Table.phpbb_topics_track
Let Eat25.01.2018
09:08:01
09:08:01
Так и есть. Но дату просмотра этой темы нужно хранить для каждого конкретного пользователя.
Вы слишком педантичны. Зачем мне знать смотрел ли я тему на 100й странице форума?Lev25.01.2018
09:08:01
09:08:01
не надо хранить дату просмотра каждой темы, если их много. Все темы старше последнего захода считать просмотренными и всё..
Subb9825.01.2018
09:08:19
09:08:19
Вы слишком педантичны. Зачем мне знать смотрел ли я тему на 100й странице форума?
Я не говорил про страницы.Я говорил про связь User - Topic
Let Eat25.01.2018
09:09:55
09:09:55
Вы хотите хранить статус просмотра каждой темы каждым пользователем. Я и спрашиваю а надо ли прям КАЖДОЙ? Например те темы что на 100й странице нет смысла уже
Subb9825.01.2018
09:10:34
09:10:34
А, понял вас теперь. Я думал, вы говорите про страницы внутри самой темы, пардон.
Darafei25.01.2018
09:10:35
09:10:35
храните все и потом напишите кронджобу, которая будет подчищать
GoogleDarafei25.01.2018
09:11:06
09:11:06
если надо будет
Subb9825.01.2018
09:11:18
09:11:18
Благодарю, в целом, смысл ясен. =)
Darafei25.01.2018
09:12:03
09:12:03
nodata ваш друг, большинство тем будет никогда не просмотрено
так что хранить надо будет только темы, в которые юзер заходил
Alex25.01.2018
09:14:04
09:14:04
А в Питере есть свободные DBA ? Зарплатная вилка 80-150, писать в личку.
Let Eat25.01.2018
09:14:47
09:14:47
Это как свободные каменщики?
Alex25.01.2018
09:15:06
09:15:06
ну кто находится в поиске работы :)
Vitaliy25.01.2018
09:37:30
09:37:30
Alex25.01.2018
09:37:54
09:37:54
как есть…
Ilia25.01.2018
09:38:22
09:38:22
А в Питере есть свободные DBA ? Зарплатная вилка 80-150, писать в личку.
Ну детяли дал бы... А то каждому в личке писать...(я не DBA нифига, я разработчик)
Alex25.01.2018
09:38:44
09:38:44
есть постгрес его надо админить :)
Yaroslav25.01.2018
09:40:21
09:40:21
Про дизайн: Как делать последовательность значений, чтобы не повторялось значение в куче асинхронных/разнесенных обработчиков? БД это делает легко. Засунули значение, инкременгт счетчика, RETURNING *
И это они гарантируют, Вы же хотите чего-то совершенно другого, нет? ;)
Alexander25.01.2018
09:43:53
09:43:53
Alex25.01.2018
09:46:01
09:46:01
Спасибо за совет.
Спрашивали описание вакансии: https://spb.hh.ru/vacancy/24009379?query=%D0%90%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%20%D0%B1%D0%B0%D0%B7%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
Mike Chuguniy25.01.2018
09:54:43
09:54:43
> Опыт работы с Astra Linux.
> Опыт работы с PostgreSQL 9.3 под Astra Linux.
Астра... Русбитех. Мои соболезнования. Особенно при наличии требований всей и всяческой секретности, основанной на мандатном доступе - весело у них там.
Alex25.01.2018
09:56:48
09:56:48
не скучно, да :)
GoogleYaroslav25.01.2018
10:07:00
10:07:00
Добрый день. Я почти закончил реализацию фичи по получению новых тем для каждого пользователя. Вот запрос на чистом SQL: http://rextester.com/XTMQV15104 Вопрос у меня следующий. Представим, что у нас накопилось 33000 тем (topics) и зарегистрировалось 17500 пользователей (users). Следовательно, в таблице participants при таких числах может быть 577 500 000 записей. Вопрос в том, насколько это хреновое решение и насколько оно будет медленно работать?
Если Вы всё ещё хотите использовать это решение, то, на первый взгляд, у Вас сам запрос далеко не лучший для этой цели (т.е. скорее всего можно переписать куда оптимальнее).Subb9825.01.2018
10:09:04
10:09:04
Да, я пока остановился на данном решении. У меня в любом случае будет не чистый запрос, я пишу на Laravel, там будет использоваться Eloquent ORM.
Сейчас покажу..
А если бы был чистый SQL, что бы Вы порекомендовали оптимизировать в данном запросе?
https://hastebin.com/umixokapos.php
Yaroslav25.01.2018
10:18:25
10:18:25
А если бы был чистый SQL, что бы Вы порекомендовали оптимизировать в данном запросе?
Во-первых, сделать подходящие для выборки индексы.
Во-вторых, я бы попробовал:
1. Использовать EXISTS вместо JOIN (у Вас из participants ничего не выбирается, и вряд ли Вам нужны дубликаты в результатах).
2. Разбить его на (темы с участием пользователя) UNION ALL (остальные темы).
3. После этого смотреть планы / сравнивать на реальных данных.Subb9825.01.2018
10:20:17
10:20:17
Благодарю. Изначально у меня было два запроса + union, но мне сказали, мол, union лишний. Я их тогда объединил.
Ilia25.01.2018
10:21:14
10:21:14
Добрый день. Я почти закончил реализацию фичи по получению новых тем для каждого пользователя. Вот запрос на чистом SQL: http://rextester.com/XTMQV15104 Вопрос у меня следующий. Представим, что у нас накопилось 33000 тем (topics) и зарегистрировалось 17500 пользователей (users). Следовательно, в таблице participants при таких числах может быть 577 500 000 записей. Вопрос в том, насколько это хреновое решение и насколько оно будет медленно работать?
Вот после OR хрень какая-то идёт.
И логика не ясна, и работать буде хреново.Subb9825.01.2018
10:22:52
10:22:52
Вот после OR хрень какая-то идёт.
И логика не ясна, и работать буде хреново.
Вот на чистом SQL: http://rextester.com/XTMQV15104Yaroslav25.01.2018
10:23:25
10:23:25
Благодарю. Изначально у меня было два запроса + union, но мне сказали, мол, union лишний. Я их тогда объединил.
Да, OR / UNION [ALL] —- это варианты выражения той же самой логики.
Проблема только в том, что в некоторых СУБД (включая PostgreSQL) JOIN-ы по OR зачастую плохо оптимизируются.Ilia25.01.2018
10:23:41
10:23:41
Там не JOIN
Но всё равно хреново
Subb9825.01.2018
10:25:11
10:25:11
Так ты это только что показывал
Да, верно. Просто я подумал, мб, Вы это не видели, раз не поняли логики в билдере.Ilia25.01.2018
10:25:42
10:25:42
Благодарю. Изначально у меня было два запроса + union, но мне сказали, мол, union лишний. Я их тогда объединил.
Зря. UNION ALL был бы лучше.
У этого запроса ещё одна проблема, ка кя подозреваю.
Дело скорее в том, что этот запрос вообще не нужно выполнять, он не выдаёт никакие полезные данные.Subb9825.01.2018
10:26:01
10:26:01
Второй?
Открыть в Telegram