Re: Parsing speed (was Re: pgstats_initstats() cost)

From: Jon Jensen <jon(at)endpoint(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)
Date: 2003-08-12 20:05:58
Message-ID: Pine.LNX.4.50.0308122003480.2882-100000@louche.swelter.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 12 Aug 2003, Tom Lane wrote:

> I have just finished running some experiments that compared a series of
> INSERTs issued via PQexec() versus preparing an INSERT command and then
> issuing new-FE-protocol Bind and Execute commands against the prepared
> statement. With a test case like the above (one target column and a
> prepared statement like "insert into abc values($1)"), I saw about a 30%
> speedup. (Or at least I did after fixing a couple of bottlenecks in the
> backend's per-client-message loop.)
[snip]
> This leaves us with a bit of a problem, though, because there isn't any
> libpq API that allows access to this speedup. I put in a routine to
> support Parse/Bind/Execute so that people could use out-of-line
> parameters for safety reasons --- but there's no function to do
> Bind/Execute against a pre-existing prepared statement. (I had to make
> a hacked version of libpq to do the above testing.)
>
> I'm beginning to think that was a serious omission. I'm tempted to fix
> it, even though we're past feature freeze for 7.4. Comments?

I think it would be well worth waiting for this feature. I often bind
parameters in Perl's DBD::Pg, looking to the future when that doesn't just
handle quoting, but also uses faster cached prepared queries. It'd be
great to see that in 7.4.

Jon

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sean Chittenden 2003-08-12 20:07:45 Re: Parsing speed (was Re: pgstats_initstats() cost)
Previous Message Rod Taylor 2003-08-12 20:05:15 Re: Parsing speed (was Re: pgstats_initstats() cost)