Re: contrib: hack for psycopg2 performance

Marko Kreen <[email protected]> Thu, 13 May 2010 10:55:14 +0300
Newsgroups gmane.comp.python.db.psycopg.devel
Message-ID <[email protected]>
On 5/12/10, Daniele Varrazzo <[email protected]> wrote:
> On Wed, May 12, 2010 at 6:04 PM, Michael Tharp
>  <gxti-1pawZKhx9Om5WRpDikjj11aTQe2KTcn/@public.gmane.org> wrote:
>  > On 05/10/2010 05:54 PM, Daniele Varrazzo wrote:
>  >>
>  >> PQexecParams has the shortcoming of being able to send only a query at
>  >> time, whereas PQexec allows to send any number in a single string,
>  >> separated by semicolons. Many people use this feature and dropping it
>  >> would be an incompatible change. How would you work around that?
>  >
>  > Can you "pipeline" statements in libpq? e.g. send three statements as
>  > separate commands but without waiting for the replies to the first two.
>
>
> I fear not: PQexec (and the different variations) blocks until the
>  result is returned. These functions are blocking wrappers around the
>  non-blocking counterparts (e.g. PQsendQuery) together with a wait
>  loop, but the docs for the latter says "PQsendQuery cannot be called
>  again (on the same connection) until PQgetResult has returned a null
>  pointer, indicating that the command is done", so I guess no luck
>  here.

Yeah, the problem is that libpq does not support pipelining.

>  > Obviously any completely transparent replacement, regardless of
>  > implementation, would need to be able to parse enough SQL to reliably split
>  > statements. I don't suppose that would be terribly difficult because SQL
>  > quoting rules are fairly simple, but it's still more work to be done.
>
>
> It is also kinda brittle in the case of new statements being
>  introduced in the syntax, but probably working at tokenizer level,
>  without syntax knowledge, is enough for a split algorithm. But I'd
>  rather have a keyword parameter on cursor.execute() to say to use
>  *Param version (when it's true, the query is assumed containing a
>  single statement) than going down the road of tokenizing the query.

Why make things complicated?  How about the following:

1) No arguments - PQexec
2) Has arguments - PQexecParams

How common are multi-statement parametrized queries anyway?

-- 
marko