Re: Berkeley DB...

> It will be interesting to see the speed differences between the
> 100,000 inserts above and those which have been PREPARE'd using
> Karel Zak's PREPARE patch. Perhaps a generic query cache could be

My test:

postmaster: -F -B 2000
rows: 100,000
table: create table (data text);
data: 37B for eache line

--- all is in one transaction

native insert: 66.522s
prepared insert: 59.431s - 11% faster

IMHO parsing/optimizing is relative easy for a simple INSERT.
The query (plan) cache will probably save time for complicated SELECTs
with functions ...etc. (like query that for parsing need look at to system
tables). For example:

insert into tab values ('some data' || 'somedata' || 'some data');

native insert: 91.787s
prepared insert: 45.077s - 50% faster

(Note: This second test was faster, because I stop X-server and
postgres had more memory :-)

The best way for large and simple data inserting is (forever) COPY, not
exist faster way.

pg's path(s) of query:

native insert: parser -> planner -> executor -> storage
prepared insert: parser (for execute stmt) -> executor -> storage
copy: utils (copy) -> storage

> amongst other things). I'm looking forward to when the 7.1 branch
> occurs... :-)

I too.

Karel