потому что из доклада следует, что протокол как раз умеет

а сишная реализация нет

Возможно имелось в виду что-то другое

@odomontois прокомментируй

https://www.postgresql.org/message-id/flat/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com#CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com Вроде как есть планы по прикручиванию асинхронности в протокол

Нашел

там речь идет про libpq

а не про протокол

libpq также именуемая выше как "говнолиба"

Ну тогда круто, че

https://www.postgresql.org/docs/devel/static/protocol-flow.html#id-1.10.5.7.4 It is not actually necessary for the frontend to wait for ReadyForQuery before issuing another command, but the frontend must then take responsibility for figuring out what happens if the earlier command fails and already-issued later commands succeed.

А на практике можно ли различить ответы?

Ну ты же помнишь, в каком порядке ты их отправлял

там скорее всего есть id

там скорее всего есть id

нет

Ну ты же помнишь, в каком порядке ты их отправлял

Оно в строгом порядке?

Оно в строгом порядке?

да

Тогда непонятно, как достигается асинхронность

Вот отправил я запрос долгий. А после него простой, но с ошибкой. Если порядок строгий - то ответ второго будет ждать долгий запрос?

Тогда непонятно, как достигается асинхронность

Никто не говорил об асинхронности на уровне протокола

Её нет

Ну я о ней говорил

Пайплайнинг без асинхронности ничего не даёт

Пайплайнинг без асинхронности ничего не даёт

Даёт. Пайплайнинг даёт очень хороший прирост

В определённых кейсах

Все равно странно, что нету асинка

Зачастую ты сам можешь предсказать с какой-то погрешностью сложность запроса

async должен на пользовательском уровне делаться мне кажется. зачем это в бекенд тащить

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

async должен на пользовательском уровне делаться мне кажется. зачем это в бекенд тащить

Не очень понял, но Юрий прав. Если бы протокол поддерживал асинхронность, это очень помогло бы

На уровне СУБД асинхронность есть, быстрые запросы могут обрабатываться независимо от долгих. А на уровне протокола воспользоваться этим затруднительно

В определённых кейсах

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

Не очень понял, но Юрий прав. Если бы протокол поддерживал асинхронность, это очень помогло бы

чем? Сейчас на одно подключение один процесс (+ параллельность внутри плана) очень просто все диагностируется

чем? Сейчас на одно подключение один процесс (+ параллельность внутри плана) очень просто все диагностируется

тем, что долгие запросы не мешают коротким

знаю ПГ как пользователь, не знаю стоит ли за это платить усложнением работы с бекендом. Мне кажется это проблема на уровене пользовательского кода все-таки.

знаю ПГ как пользователь, не знаю стоит ли за это платить усложнением работы с бекендом. Мне кажется это проблема на уровене пользовательского кода все-таки.

для пользователя ничего не изменится. Это всё будет внутри драйверов

еще как изменится

Всегда ценил ПГ за простоту. один connection один процесс. Все последовательно внутри процесса. Диагностика супер простая.

ну и нужно открыть 100500 конекшенов для нормальной нагрузки

а так 5 конектов открыл и готов

вот именно. о чём и говорят, надо просто юзать отдельные connection-ы. Не пихать сложную логику асинка в протокол.

соединения не бесплатные

если можно сделать больше работы с одним и тем же количеством соединений - почему нет

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

это же как с соединениями и блокирующими операциями. Можно отправить запрос и заблокировать поток. А можно отправить запрос и продолжить использовать поток для других вещей.

так так и надо делать)) зачем тут протокол? соединения в данном случае копейки, так как все равно вы их держите, и ровно столько сколько можете на стороне ПГ запустить процессов.

так так и надо делать)) зачем тут протокол? соединения в данном случае копейки, так как все равно вы их держите, и ровно столько сколько можете на стороне ПГ запустить процессов.

еще раз. Соединение - это не копейки. И я просто провел аналогию. Зачем держать кучу соединений, когда всё равно они почти всё время простаивают?

это копейки. установить соединение это дорого.

в телеграме можно как-то к человеку вешать бейджик: "Школьник" ?

если будет 3 соединения и 9 postgres-процессов, то добавить 6 соединений (которые активны) ничего стоить не будет.

если будет 3 соединения и 9 postgres-процессов, то добавить 6 соединений (которые активны) ничего стоить не будет.

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

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

почему дорого? может расскажете?

от уровня jvm до ОС, как все происходит и сколько всего нужно.

если будет 3 соединения и 9 postgres-процессов, то добавить 6 соединений (которые активны) ничего стоить не будет.

Хз как в постгре, подозреваю схоже в общем. Оракл для каждого соединения создает у себя сессии. Память под них выделяется в специальной области. И это весьма тяжелая вещь.

Доклад Олега классный, кассандра тоже

Хз как в постгре, подозреваю схоже в общем. Оракл для каждого соединения создает у себя сессии. Память под них выделяется в специальной области. И это весьма тяжелая вещь.

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

Хз как в постгре, подозреваю схоже в общем. Оракл для каждого соединения создает у себя сессии. Память под них выделяется в специальной области. И это весьма тяжелая вещь.

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

+ усложните работу с сервером. про оракл не скажу. postgres лучший. ps aux | grep postgres | ... решает 90% проблем.

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

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

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

+ усложните работу с сервером. про оракл не скажу. postgres лучший. ps aux | grep postgres | ... решает 90% проблем.

Вот уж явно не видели проблем. Универсальный инструмент с кучей ручек надо тюнить под кейсы. А если нет, то либо все просто и без нагрузки/объемов либо дикий фарт с кейсом и дефолтами.

если про ПГ, абсолютно согласен)

Вот уж явно не видели проблем. Универсальный инструмент с кучей ручек надо тюнить под кейсы. А если нет, то либо все просто и без нагрузки/объемов либо дикий фарт с кейсом и дефолтами.

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

ну да PG не коробочный продукт. linux way

Посоветуйте, есть REST метод, который принимает на вход JSON с кучей параметров, надо его "закэшировать", чтобы повторно не вычислять для тех же самых параметров. Но эти параметры - это класс с вложенными коллекциями, и в целом около 10 параметров разных - то есть класть их все в базу (постгрес) как поля - не вариант. Что если этот класс сериализовать в JSON с одними и теми же настройками сериализации и положить в одно поле базы и по этому полю искать. Нормальное решение или есть лучше варианты?

ERROR: S client not available

можно посчитать несколько хешей, чтобы на 99.99999 процентов быть уверенным что всё ок и класть в базу только хеши

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

но такой вариант тоже норм

ну для этого я предложил считать 2 хеша

Посоветуйте, есть REST метод, который принимает на вход JSON с кучей параметров, надо его "закэшировать", чтобы повторно не вычислять для тех же самых параметров. Но эти параметры - это класс с вложенными коллекциями, и в целом около 10 параметров разных - то есть класть их все в базу (постгрес) как поля - не вариант. Что если этот класс сериализовать в JSON с одними и теми же настройками сериализации и положить в одно поле базы и по этому полю искать. Нормальное решение или есть лучше варианты?

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

Посоветуйте, есть REST метод, который принимает на вход JSON с кучей параметров, надо его "закэшировать", чтобы повторно не вычислять для тех же самых параметров. Но эти параметры - это класс с вложенными коллекциями, и в целом около 10 параметров разных - то есть класть их все в базу (постгрес) как поля - не вариант. Что если этот класс сериализовать в JSON с одними и теми же настройками сериализации и положить в одно поле базы и по этому полю искать. Нормальное решение или есть лучше варианты?

мы UUID считаем для такого кейса

но есть нюанс, json не гарантирует же порядок полей

но есть нюанс, json не гарантирует же порядок полей

можно гарантировать самому

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

ну для этого я предложил считать 2 хеша

понял, неплохо

Ну если база резиновая, то можно класть числовой хеш + json

да, вполне резиновая

так будет 100% гарантия и скорость приемлемая

полагаю, что можно выбрать один хороший хеш и забить

Ну вообще да, я тоже так думаю

типа там sha256

но всё равно проблемы с репрезентацией параметров, нужно очень очень быть уверенным, что генерируешь одну и ту же символьную последовательность

а какого рода коллекции?

есть лучшие решения

а почему постгря в качестве кеша?

коллекции - листы, отсортирую их перед сериализацией

листы чего?

а почему постгря в качестве кеша?

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

листы чего?

листы UUID-ов

листы UUID-ов

а что вычисляется-то, сам JSON?

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

а json входящий насколько большой?

да небольшой

смотря сколько UUID-ов в коллекциях

Привет! я посмотрел доклад Олега, сериализация типов из скала в касандра типы все класнно, но... может я что не понял. зачем сериализировать getOffer function?? или мы там храним по-сути кэш всех вызовов функции и она автоматом кэшируется неявно в кассандру? я что-то не уловил как использовать либу и что в итоге мы получим

Привет! я посмотрел доклад Олега, сериализация типов из скала в касандра типы все класнно, но... может я что не понял. зачем сериализировать getOffer function?? или мы там храним по-сути кэш всех вызовов функции и она автоматом кэшируется неявно в кассандру? я что-то не уловил как использовать либу и что в итоге мы получим

Получим getOffer, который будет возвращать исторические данные, даже когда оригинальный код по той или иной причине будет генерить ошибки

прикольно! спасибо, вроде понял. то-есть кэширование истории экзекьюшена, и если вдруг там после обновления что-то поламалось оно будет работать... очень интересно.. спасибо ?