On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I think the limit has to be in terms of a percentage of the table size.
> > For example, if we do one SELECT on a table with all non-dirty pages, it
> > would be good to know that 5% of the pages were pruned --- that tells me
> > that another 19 SELECTs will totally prune the table, assuming no future
> > writes.
>
> This seems simple to implement: keep two counters, where the second one
> is pages we skipped cleanup in. Once that counter hits SOME_MAX_VALUE,
> reset the first counter so that further 5 pages will get HOT pruned. 5%
> seems a bit high though. (In Simon's design, SOME_MAX_VALUE is
> essentially +infinity.)
Oh, I pulled 5% out of the air. Thinking of a SELECT-only workload,
which would be our worse case, I was thinking how many SELECTS running
through HOT update chains would it take to be slower than generating the
WAL to prune the page. I see the percentage as something that we could
reasonably balance, while a fixed page count couldn't be analyzed in
that way.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
