concurrent connections is worse than serialization?

From: Wei Weng <wweng(at)kencast(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: concurrent connections is worse than serialization?
Date: 2002-08-13 20:39:24
Message-ID: 1029271170.16828.7.camel@Monet
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

I have a testing program that uses 30 concurrent connections
(max_connections = 32 in my postgresql.conf) and each does 100
insertions to a simple table with index.

It took me approximately 2 minutes to finish all of them.

But under the same environment(after "delete From test_table, and vacuum
analyze"), I then queue up all those 30 connections one after another
one (serialize) and it took only 30 seconds to finish.

Why is it that the performance of concurrent connections is worse than
serializing them into one?

I was testing them using our own (proprietary) scripting engine and the
extension library that supports postgresql serializes the queries by
simply locking when a query manipulates a PGconn object and unlocking
when it is done. (And similiarly, it creates a PGconn object on the
stack for each concurrent queries.)

Thanks

--
Wei Weng
Network Software Engineer
KenCast Inc.

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2002-08-14 02:43:18 Re: [SQL] 16 parameter limit
Previous Message Aaron Held 2002-08-13 18:45:42 Re: update on a large table