Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 515A1118B7D3 for ; Wed, 4 Apr 2012 20:07:14 -0300 (ADT) Received: from smtp.01.com ([199.36.142.181]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SFZID-0007vq-Rb for pgsql-hackers@postgresql.org; Wed, 04 Apr 2012 23:07:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id CC1B14F5C46 for ; Wed, 4 Apr 2012 18:06:55 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXM2yXnDx+uC for ; Wed, 4 Apr 2012 18:06:55 -0500 (CDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AB77C4F5C54 for ; Wed, 4 Apr 2012 18:06:55 -0500 (CDT) Received: from Sidney-Stratton.local (70-36-143-92.dsl.dynamic.sonic.net [70.36.143.92]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 3F4AA4F5C51; Wed, 4 Apr 2012 18:06:55 -0500 (CDT) Message-ID: <4F7CD40E.10401@agliodbs.com> Date: Wed, 04 Apr 2012 16:06:54 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pgsql-hackers@postgresql.org, Jignesh Shah Subject: Re: patch: improve SLRU replacement algorithm References: <11561.1333580573@sss.pgh.pa.us> In-Reply-To: <11561.1333580573@sss.pgh.pa.us> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201204/188 X-Sequence-Number: 205991 On 4/4/12 4:02 PM, Tom Lane wrote: > Greg Stark writes: >> On Wed, Apr 4, 2012 at 9:34 PM, Simon Riggs wrote: >>> Why is this pgbench run accessing so much unhinted data that is > 1 >>> million transactions old? Do you believe those numbers? Looks weird. > >> I think this is in the nature of the workload pgbench does. Because >> the updates are uniformly distributed, not concentrated 90% in 10% of >> the buffers like most real-world systems, (and I believe pgbench only >> does index lookups) the second time a tuple is looked at is going to >> average N/2 transactions later where N is the number of tuples. > > That's a good point, and it makes me wonder whether pgbench is the right > test case to be micro-optimizing around. It would be a good idea to at > least compare the numbers for something with more locality of reference. Jignesh, would DVDstore help for this? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com