Re: patch: improve SLRU replacement algorithm - Mailing list pgsql-hackers

From Jignesh Shah
Subject Re: patch: improve SLRU replacement algorithm
Date
Msg-id CAGvK12UO_39BY0QhpJA8Wqi8nZBv+8Z7XTRe3Z27m9+hvqJmUA@mail.gmail.com
Whole thread Raw
In response to Re: patch: improve SLRU replacement algorithm  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Wed, Apr 4, 2012 at 7:06 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 4/4/12 4:02 PM, Tom Lane wrote:
>> Greg Stark <stark@mit.edu> writes:
>>> On Wed, Apr 4, 2012 at 9:34 PM, Simon Riggs <simon@2ndquadrant.com> 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

I will try this out next week.. I am scrounging for decent hardware
and I think I found one.. though I will get access to it on Monday.

The way you could do locality in DVDStore is do the build with say
10GB size but while running the actual run just mention the size as
1GB and that should get you the 10% active population scenario.


Regards,
Jignesh


pgsql-hackers by date:

Previous
From: Shigeru HANADA
Date:
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Next
From: Jeff Davis
Date:
Subject: Re: pg_upgrade incorrectly equates pg_default and database tablespace