Да, конечно влияет

Ясно. Меня просто смутила фраза "стабильно висит 200 активных подключений"

Ну они отображаются как в мониторинге облака, так и через pg_stat_activity. Где статусы то idle, то idle in transaction

>допустим не подсвечивает переменную, когда на неё встаёшь
так выглядит в vi

а вот, как я хотел бы видеть

Нажмите "*" (+'hlsearch').
Или, если это нужно автоматически, поищите (или напишите, с виду это несложно) plugin, который такое делает.

спасибо, hlsearch решает)

хотя, всё же нет;
не совсем удобно — так понимаю, нужно каждый раз вбивать hlsearch, когда хочешь выделить переменную. Сам редактор при перемещении по тексту, по другим переменным, их автоматически не подсвечивает (ну и подстветку от hlsearch не убирает, когда уже ушёл со старого места)

hlsearch — это же опция, см. help (да и вообще, первым делом читайте его про всё в vim).
Поэтому нажимать достаточно *.
И, как я написал выше, если нужно автоматически, то стоит поискать (мне просто не нужно).  ;)

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

Всем привет, возможно, вопрос вообще не в тему ( он скорее по географии / геометрии ), подскажите, пожалуйста:
В postgres есть встроенные типы — circle, point.
Я хочу создать 2 таблицы, одна — города ( содержит в себе поле, которое является типом circle ), и таблица адресов — содержит в себе поле являющиеся типом point, я нашёл оператор @>. который проверяет содержит ли первый объект второй, потестил на тестовой табличке, вроде всё гуд, всё понятно, вопрос заключается в следующем:
планируется в точках ( т.е как центр окружности городов, и адресов ) хранить широту, долготу, вот, и если я храню широту и долготу ( из себя представляют градусы ), как можно задавать радиус ? можно ли используя эту функцию, считать, что точка будет внутри окружности ( я так понимаю, что под капотом неравенство из школы ) ?  — смущает то, что у меня не координаты по сути, а углы

это субъективно. для меня vim — самая нормальная IDE

посмотрите, может лучше расширение PostGis использовать

>  что уже везде есть:)

О-хо-хо. Где "везде" есть конкретно вот это вот (я уверен, что есть более одной IDE, где этого нет)?

> то в этом всё же и есть ценность нормальных иде

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

> цель — разработка своего приложения, а не разработка нового редактора :)

Ну так можно взять совершенно случайный редактор (почему бы не ed или notepad.exe?), и совсем ничего в нём не настраивать, не искать (plugins, например) и не осваивать (не открывать документацию), так получается?
В общем, это преувеличение, IMNSHO. А вот изучение и настройка под себя, как мне кажется, окупаются.

Да, лучше postgis. И тут где-то был даже чат по нему, кстати.

Установил pgbouncer наконец. Устанавливал через докеры сначала, различные образы, но их простая настройка чуть из себя не вывела :) В итоге установил его на отдельном сервере и связал с базой по внутреннему IP. Все настройки pgbouncer'a были стандартными за исключением: pool_mode=session, default_pool_size=2000, max_client_conn=2000, если я всё правильно понял из источников. Убрал пул из SQLAlchemy, соединил её с pgbounce и вроде всё работает, но не совсем так, как ожидалось. Тестировал различные конфигурации воркеров и вот что получилось. Ниже будет график из Rabbitmq по обработке сообщений в очереди. И я сейчас не понимаю, где искать затуп, который случился.

(1) — поднято 10 машин (2 vCPU, 1GB RAM), на каждой из них работает воркер со следующими конфигурациями: 1 процесс с 1 потоком (в дальнейшем -p 1 -t 1). Скорость обработки сообщений вы видите на графике (отрезок (1)). Всё супер стабильно, скорость отличная. (напомню, что при запуске воркера на домашней машине с параметрами -p 1 -t 1 скорость обработки была ~1 сообщение/с). На клауде с такими параметрами обрабатывалось 15 сообщений/с.

(2) — поднятно 33 машины (2 vCPU, 1GB RAM), на каждой из них работает воркер с такими же конфигурациями что и в предыдущем ((1)) случае. Опять же, скорость выросла как и ожидалась, она стабильна. Всё отлично.

(3) — поднята 1 машина (2 vCPU, 1GB RAM). На неё работает воркер с параметрами: 1 процесс 50 потоков. Скорость, как вы видите, существенно отличается даже от случая (1), где в сумме было поднято 10 потоков. Во-первых, скорость слишком нестабильная, число обработки скачет от 60 до 120, во-вторых, 50 потоков > 10 потоков, поэтому ожидается скорость больше чем была, не так ли? Это проблема непосредственно с pgbouncer, или всё-таки с воркером (в чём я на данный момент сомневаюсь, ибо до этого количество указанных потоков прямо соответствовало скорости обработки сообщений)

Немного не по теме, наверное, но у меня вопрос. Если вы на каждой машине запускаете ровно один воркер (1 питон-процесс), то зачем вам 2 vCPU на них, учитывая, что по сути задействуется лишь одно ядро? 1 питон процесс два ядра загрузить не может. Или я что-то не так понял

"поэтому ожидается скорость больше чем была, не так ли" - не знаю, для меня это не очевидно в случае с Питоном. Вы там в какой-нибудь GIL не упираетесь?

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