On Thu, Apr 16, 2015 at 03:41:54PM +0100, Simon Riggs wrote: > That is how we arrive at the idea of a cleanup limit, further enhanced by a > limit that applies only to dirtying clean blocks, which we have 4? recent > votes > in favour of. > > I would personally be in favour of a parameter to control the limit, since > whatever we chose is right/wrong depending upon circumstances. I am however > comfortable with not having a parameter if people think it is hard to tune > that, which I agree it would be, hence no parameter in the patch.
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. If there are future writes, they would dirty the pages and cause even more pruning, but the 5% gives me the maximum pruning number of SELECTs. If there aren't another 19 SELECTs, do I care if the table is pruned or not? Probably not. Measuring in page count doesn't do that, and a large table could receive millions of selects before being fully cleaned. Also, I am also not sure we should be designing features at this stage in our release process. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
