<p dir="ltr"><br /> On 15 Apr 2015 15:43, "Simon Riggs" <<a
href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>>wrote:<br /> ><br /> > It all depends upon who
isbeing selfish. Why is a user "selfish" for<br /> > not wanting to clean every single block they scan, when the
people<br/> > that made the mess do nothing and go faster 10 minutes from now?<br /> > Randomly and massively
penalisinglarge SELECTs makes no sense. Some<br /> > cleanup is OK, with reasonable limits, which is why that is
proposed.<pdir="ltr">I don't think it's productive to think of a query as a different actor with only an interest in
itsown performance and no interest in overall system performance.<p dir="ltr">From a holistic point of view the
questionis how many times is a given hit chain going to need to be followed before it's pruned. Or to put it another
way,how expensive is creating a hot chain. Does it cause a single prune? a fixed number of chain readers followed by a
prune?Does the amount of work depend on the workload or is it consistent?<p dir="ltr">My intuition is that a fixed
cutofflike "five pages" is dangerous because if you update many pages there's no limit to the number of times they'll
beread before they're all pruned. The steady state could easily be that every query is having to read hot chains
forever.<pdir="ltr">My intuition, again, is that what we need is a percentage such as "do 10 prunes then ignore the
next1000 clean pages with hot chains. That guarantees that after 100 selects the hot chains will all be pruned but each
selectwill only prune 1% of the clean pages it sees.