On Tue, 21 Apr 2009, Stephen Frost wrote:
* James Mansion (james@xxxxxxxxxxxxxxxxxxxxxx) wrote:
david@xxxxxxx wrote:
on the other hand, when you have a full queue (lots of stuff to
insert) is when you need the performance the most. if it's enough of a
win on the database side, it could be worth more effort on the
applicaiton side.
Are you sure preparing a simple insert is really worthwhile?
I'd check if I were you. It shouldn't take long to plan.
Using prepared queries, at least if you use PQexecPrepared or
PQexecParams, also reduces the work required on the client to build the
whole string, and the parsing overhead on the database side to pull it
apart again. That's where the performance is going to be improved by
going that route, not so much in eliminating the planning.
in a recent thread about prepared statements, where it was identified that
since the planning took place at the time of the prepare you sometimes
have worse plans than for non-prepared statements, a proposal was made to
have a 'pre-parsed, but not pre-planned' version of a prepared statement.
This was dismissed as a waste of time (IIRC by Tom L) as the parsing time
was negligable.
was that just because it was a more complex query to plan?
David Lang
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
