я бы посмотрел на код. думаю, там запрос компилируется 1000000 раз в цикле

ну я-же не наркоман

можно еще в этот цикл засунуть import чего-нить, для гарантии

ну я-же не наркоман

ну так код тестов -_-

ну так код тестов -_-

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

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

Я не нашел способа

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

Ты смотрел что внутри простого селекта происходит?

можно еще в этот цикл засунуть import чего-нить, для гарантии

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

https://pastebin.com/zqQf8T5D

Вот, можно посмотреть предметно

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

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

асинхронно изо всех щелей?)

Да хоть бы и так.

где тут алхимия то, в пастебине?

Закомментирована

Оба куска, что рабочий, что закоментированный, делают одно и тоже

странно, ведь закоментированный код - самый быстрый

не вижу там в закомментированном алхимической query - я тупой?

Бляяя

https://i.imgur.com/aEnFEOH.png

Вот, что должно было быть в закоменченом коде

ну тут не скомпилируешь :)

хуле. если даже таблицу каждый раз вычисляют

Нихуя, там return self._table

да, да, бывает. Раньше в self.from_row было больше параметров

Да я понимаю, чо ты как это.

Не мог не доебаться прост. Ты как первый раз.

Ты тупо вытаскиваешь из базы данные из одной и той же таблицы представляя айдишники?

И каждый раз вызываешь это?

Подставляя*

да

то-есть запрос-то не меняется. В худшем случае их два, с разными where

Ну как бы да

Только вот compile вызывается внутри execute, а не в момент "построения"

вот туточки

покажи пример реального запроса, который ты собрал этим говном

что в базу уходит

или покажи объект query интроспекцией

SELECT profiles.id AS profiles_id, profiles.created_at AS profiles_created_at, profiles.updated_at AS profiles_updated_at, profiles.name AS profiles_name, profiles.nickname AS profiles_nickname, profiles.phone AS profiles_phone, profiles.avatar_id AS profiles_avatar_id, profiles.device_types AS profiles_device_types, profiles.visibility AS profiles_visibility, profiles.last_activity AS profiles_last_activity, profiles.status AS profiles_status, profiles.ref_images AS profiles_ref_images FROM profiles WHERE profiles.id IN (%(id_1)s)

то есть за вычетом profiles.id IN (%(id_1)s) нихрена в целом не меняется от раза к разу?

да

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

я просто в этой асинхронной лапше в полночь не понимаю и разбираться даже не встает

В хеш положить.

Меньшая из проблем

А синхронно оно так же тупит?

я не спрашиваю, бОльшая или мЕньшая

я хочу понять как тебе помочь, а ты пока выебываешься

Черт его знает, но код, который тупит в профилировании, синхронный

я хочу понять как тебе помочь, а ты пока выебываешься

Окей, бросил-бы в dict, а ключи сделал константами и писал-бы их везде руками

compiled_query = query.statement.compile() params = compiled_query.params prepared_sql = compiled_query.string

{AttributeError}'Select' object has no attribute 'statement'

pg2_cursor = query.session.connection().connection.cursor() sql = pg2_cursor.mogrify(prepared_sql, params)

бля, это бы говно локально в дебаггер

так вот уже

не ставить же асинхронщину себе бесплатно

и вслепую гадать. это я из рабочего кода взял

а твой query не ORM'ный?

Но в целом суть ясна. mogrify помножит промежуточный SQL на параметры и вернет строку?

Но в целом суть ясна. mogrify помножит промежуточный SQL на параметры и вернет строку?

Да, там все решения такие. Объекты сам создашь из цикла

А там народ пишет, что для алхимии компиляция - самое дорогое и долгое

Аж передернуло

Аж передернуло

Ай не говори, хорошо, что в сторонке валяется и все идентификаторы числовые

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

Но в целом суть ясна. mogrify помножит промежуточный SQL на параметры и вернет строку?

ага, которую тупо хоть в psql вставляй руками и дергай

query = sa.select([1]) query.compile().string 'SELECT 1'

блеск

спасибо

во

а query.compile().params покажи ради прикола?

{}

Там ведь select([1])

хм...

да, чет странно. попробуй на более "сложном" селекте

чтобы where было. а то подставлять имхо некуда просто эти параметры

вот! :)

.string кидаешь в свой dict, а mogrify потом подставит нужное и в execute

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

Всё завалено orm-примерами

А документацию алхимии писали явно под спайсами

Ну так на название посмотри.

А документацию алхимии писали явно под спайсами

Под перцем

вообще я думаю тебе вот сюда стоит посмотреть https://magicstack.github.io/asyncpg/current/api/index.html#prepared-statements

Он втирал его в глаза

вообще я думаю тебе вот сюда стоит посмотреть https://magicstack.github.io/asyncpg/current/api/index.html#prepared-statements

Я тоже искал их, но что-то не нашел, только руками собирать

поди conn.prepare() ченить наварит

Для алхимии

вот жопа в том, что в asyncpg скорее всего не будет mogrify()

Будет, я находил

где-то по дороге от psycopg2 в asyncpg его сто пудов и выкинули

ну тогда и курсор найдешь :))

Только вот он в какой глубине дремлет

Только вот он в какой глубине дремлет

Там ниже есть ворнинг про пгбаунсер, ахтунг.