Re: Parsing speed (was Re: pgstats_initstats() cost) - Mailing list pgsql-hackers

From Jon Jensen
Subject Re: Parsing speed (was Re: pgstats_initstats() cost)
Date
Msg-id Pine.LNX.4.50.0308122003480.2882-100000@louche.swelter.net
Whole thread Raw
In response to Parsing speed (was Re: pgstats_initstats() cost)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)
Next
From: Sean Chittenden
Date:
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)