Re: psycopg3, prepared statements

Cause (query, types) can give more combinations than (query,)?

On Wed, 23 Dec 2020 at 15:12, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 12/23/20 2:53 PM, Daniele Varrazzo wrote:
> > On Tue, 22 Dec 2020 at 22:36, Daniele Varrazzo
> > <daniele(dot)varrazzo(at)gmail(dot)com> wrote:
> >>
> >> On Tue, 22 Dec 2020 at 05:39, Vladimir Ryabtsev <greatvovan(at)gmail(dot)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(dot)klaver(at)aklaver(dot)com
>