Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 0DD6DB5DC4A
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Fri,  4 Nov 2011 11:08:14 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 01597-01 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Fri,  4 Nov 2011 14:08:07 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 8D22FB5DBDF
	for <pgsql-admin@postgresql.org>; Fri,  4 Nov 2011 11:08:07 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id pA4E86Us006406;
	Fri, 4 Nov 2011 10:08:06 -0400 (EDT)
To: Shivakumar Ramannavar <shivasr@gmail.com>
cc: pgsql-admin@postgresql.org
Subject: Re: Fwd: My Query to insert and retrieve takes time 
In-reply-to: 
 <CACdOLXae4kZcKBHpe4vyhSy589qV06FUtoEoD=33yZLGBDVNgw@mail.gmail.com>
References: 
 <CACdOLXa12h6oN406mqZAZaCJG3G6hK=eTx_YhthJZU6vomPkAA@mail.gmail.com>
	<CACdOLXae4kZcKBHpe4vyhSy589qV06FUtoEoD=33yZLGBDVNgw@mail.gmail.com>
Comments: In-reply-to Shivakumar Ramannavar <shivasr@gmail.com>
	message dated "Fri, 04 Nov 2011 14:57:04 +0530"
Date: Fri, 04 Nov 2011 10:08:06 -0400
Message-ID: <6405.1320415686@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-3.101 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-1.201
X-Spam-Level: 
X-Archive-Number: 201111/10
X-Sequence-Number: 38604

Shivakumar Ramannavar <shivasr@gmail.com> writes:
> Here is some observation drawn from PostgreSQL performance testing:

> There are around 310,000 records, it takes 8.313 milliseconds to
> retrieval/search a record, and it takes 8.321 milliseconds more to update a
> record.

It was already pointed out to you that these numbers are suspiciously
close together, and also suspiciously close to the rotation time of a
7200RPM disk.  It seems very likely that you have configured things so
that each operation is done in a transaction that has to be explicitly
committed to disk, thus requiring a write to WAL, which would limit the
transaction rate to one per rotation.  However, since you haven't shown
us anything about how the queries are being issued, we can't confirm
or disprove that theory.

Consider batching multiple operations into a single transaction.
Turning off synchronous_commit is another possibility, depending on
what your crash-safety requirements are.

			regards, tom lane