Re: psycopg3, prepared statements
От | Adrian Klaver |
---|---|
Тема | Re: psycopg3, prepared statements |
Дата | |
Msg-id | c07974b0-471b-340d-ee6e-1a145fbd8999@aklaver.com обсуждение исходный текст |
Ответ на | Re: psycopg3, prepared statements (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: psycopg3, prepared statements
|
Список | psycopg |
On 12/23/20 2:53 PM, Daniele Varrazzo wrote: > On Tue, 22 Dec 2020 at 22:36, Daniele Varrazzo > <daniele.varrazzo@gmail.com> wrote: >> >> On Tue, 22 Dec 2020 at 05:39, Vladimir Ryabtsev <greatvovan@gmail.com> wrote: > > > Heads up about this: it's better than I thought! > > I wrote a first implementation of the prepared statements cache using > the query as a key, but it's actually enough to use the (query, types) > tuple in order to tell apart statements that are executed with > different types. This way even the "SELECT %s" case won't be a > problem. Of course a statement executed with a mix of types will be > prepared later than `prepare_threshold`, but I think it's perfectly Alright I was following you until you got to above. I'm not following why it would overshoot prepare_threshold? > acceptable: the case doesn't happen often and having the query > prepared after 10 times instead of 5 doesn't change much if it will be > executed hundreds of times or more. > > What seems a feature-complete branch is available in [1]. The tests > [2] illustrate the main behaviour of the prepared statements system. > > [1]: https://github.com/psycopg/psycopg3/tree/prepared-statements>. > [2]: https://github.com/psycopg/psycopg3/blob/prepared-statements/tests/test_prepared.py > > Off to do some benchmarks now... > > -- Daniele > -- Adrian Klaver adrian.klaver@aklaver.com
В списке psycopg по дате отправления: