Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id D6583B5DCA8 for ; Tue, 12 Jul 2011 11:43:27 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 93361-05-2 for ; Tue, 12 Jul 2011 14:43:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mail.postgresql.org (Postfix) with ESMTP id 60D40B5DCC2 for ; Tue, 12 Jul 2011 11:43:20 -0300 (ADT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QgeBA-0008OX-B3 for pgsql-performance@postgresql.org; Tue, 12 Jul 2011 16:43:16 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jul 2011 16:43:16 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jul 2011 16:43:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Ivan Voras Subject: Re: UPDATEDs slowing SELECTs in a fully cached database Date: Tue, 12 Jul 2011 16:43:03 +0200 Lines: 33 Message-ID: References: <4E16479D.3050605@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201107/110 X-Sequence-Number: 44322 On 12/07/2011 16:18, Merlin Moncure wrote: > On Tue, Jul 12, 2011 at 8:22 AM, Ivan Voras wrote: >> On 08/07/2011 01:56, lars wrote: >> >>> Setup: >>> PostgreSQL 9.1beta2 on a high memory (~68gb, 12 cores) EC2 Linux >>> instance (kernel 2.6.35) with the database and >>> WAL residing on the same EBS volume with EXT4 (data=ordered, barriers=1) >>> - yes that is not an ideal setup >>> (WAL should be on separate drive, EBS is slow to begin, etc), but I am >>> mostly interested in read performance for a fully cached database. >> >> I know you said you know these things - but do you really know the (huge) >> extent to which all your IO is slowed? Even context switches in a >> virtualized environment are slowed down by a huge margin - which would make >> practically all in-memory lock operations very slow - much slower than they >> would be on "real" hardware, and EBS by definition is even slower then >> regular private virtual storage environments. I regrettably didn't bookmark >> the page which did exact measurements of EBS, but >> http://www.google.com/search?q=how+slow+is+ec2 will illustrate my point. (of >> course, you may already know all this :) ). > > sure, but the OP's question is valid: in postgres, readers don't block > writers, so why is the reader waiting? Yes, but I'm suggesting a different question: are we sure we are not seeing the influences of the environment (EC2+EBS) instead of the software system? > We need some more information here. Definitely.