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

Поиск
Список
Период
Сортировка
От Jon Jensen
Тема Re: Parsing speed (was Re: pgstats_initstats() cost)
Дата
Msg-id Pine.LNX.4.50.0308122003480.2882-100000@louche.swelter.net
обсуждение исходный текст
Ответ на Parsing speed (was Re: pgstats_initstats() cost)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: Parsing speed (was Re: pgstats_initstats() cost)
Следующее
От: Sean Chittenden
Дата:
Сообщение: Re: Parsing speed (was Re: pgstats_initstats() cost)