Subject: Re: CPU costs of random_zipfian in pgbench
To: Fabien COELHO <coelho@cri.ensmp.fr>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Georgios Kokolatos <gkokolatos@pm.me>,
 PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
References: <b5e172e9-ad22-48a3-86a3-589afa20e8f7@2ndquadrant.com>
 <alpine.DEB.2.21.1902221716430.4182@lancre>
 <155246731010.16480.15850913449923768119.pgcf@coridan.postgresql.org>
 <alpine.DEB.2.21.1903131048290.4059@lancre> <3703.1553360483@sss.pgh.pa.us>
 <alpine.DEB.2.21.1903231802440.18811@lancre>
 <alpine.DEB.2.21.1903231910020.18811@lancre>
 <alpine.DEB.2.21.1903231944420.18811@lancre>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <7fe3b752-e204-6735-e6ef-2c54b56b024d@2ndquadrant.com>
Date: Sun, 24 Mar 2019 04:06:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.1903231944420.18811@lancre>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 3/23/19 7:45 PM, Fabien COELHO wrote:
> 
>>>> What is the point of that, and if there is a point, why is it nowhere
>>>> mentioned in pgbench.sgml?
>>
>> The attached patch simplifies the code by erroring on cache overflow,
>> instead of the LRU replacement strategy and unhelpful final report.
>> The above lines are removed.
> 

Eh? Do I understand correctly that pgbench might start failing after
some random amount of time, instead of reporting the overflow at the
end? I'm not sure that's really an improvement ...

Why is the cache fixed-size at all?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services