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
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) |