Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 4AD71633E47 for ; Wed, 4 Nov 2009 16:44:11 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 07859-07 for ; Wed, 4 Nov 2009 20:44:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id AEC386331C2 for ; Wed, 4 Nov 2009 16:44:03 -0400 (AST) 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 nA4Khm0J020918; Wed, 4 Nov 2009 15:43:48 -0500 (EST) To: Brian Karlak cc: Jeff Janes , pgsql-performance@postgresql.org Subject: Re: maintaining a reference to a fetched row In-reply-to: <82545852-CE9E-4B0D-ABAB-B628C888D086@metaweb.com> References: <22AC581D-50D1-4863-9FDE-35EDDB171269@metaweb.com> <82545852-CE9E-4B0D-ABAB-B628C888D086@metaweb.com> Comments: In-reply-to Brian Karlak message dated "Wed, 04 Nov 2009 09:41:54 -0800" Date: Wed, 04 Nov 2009 15:43:47 -0500 Message-ID: <20917.1257367427@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200911/49 X-Sequence-Number: 36217 Brian Karlak writes: > On Nov 4, 2009, at 8:47 AM, Jeff Janes wrote: >> Why would the index scan take 1 ms two of the times it is done but 5ms >> the third time? Isn't it the same index scan each time? Or does the >> change in queue.status change the plan? > The final update is a different query -- just a plain old update by ID: > UPDATE queue_proc set status = 'proc' where id = %s ; > This update by ID takes ~2.5ms, which means it's where the framework > is spending most of its overhead. Well, if SELECT FROM queue_proc where id = %s takes 1ms and the update takes 2.5ms, then you've got 1.5ms going into updating the row, which means it's not going to get a whole lot faster by switching to some other WHERE condition. Maybe you should look at cutting back on indexes and/or triggers attached to this table. regards, tom lane