From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: insert performance riddle |
Date: | 2005-08-11 19:37:00 |
Message-ID: | 20050811193700.GA94258@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Aug 11, 2005 at 12:59:32PM -0600, Ed L. wrote:
> > Michael, you seem to have nailed it. The local inserts (via
> > Unix domain sockets?) that were running at 6 QPS ran at 6800
> > to 41000 QPS in a PL/pgSQL function.
>
> Here's another part of the riddle. The query durations for the
> individual inserts as logged in the server log are ranging
> 100ms-500ms per insert when connecting via DBI/DBD::Pg from
> localhost. Inside pl/pgsql, they're clearly averaging faster
> than 1ms per insert. I would have thought those times were
> independent of the client communication layers...?
Have you done any client-side tests that eliminate Perl? I'd suggest
writing a little C program so you can measure libpq's performance
without the extra layers of Perl and DBI/DBD::Pg. Test both local
(Unix socket) and network (IPv4 or IPv6 socket) connections.
A couple of months ago, Tom Lane noticed that benchmarks using
DBD::Pg make PostgreSQL look worse than it deserves:
http://archives.postgresql.org/pgsql-interfaces/2005-06/msg00003.php
--
Michael Fuhr
From | Date | Subject | |
---|---|---|---|
Next Message | CSN | 2005-08-11 20:02:45 | ERROR: plphp: unable to register function "plphp_proc_4947785_trigger" |
Previous Message | Shane | 2005-08-11 19:33:24 | Re: Index not being used unless enable_seqscan=false |