On Fri, Apr 22, 2016 at 8:06 AM, Kevin Grittner <kgri...@gmail.com> wrote: > On Thu, Apr 21, 2016 at 4:13 PM, Kevin Grittner <kgri...@gmail.com> wrote: > >> I have your test case running, and it is not immediately >> clear why old rows are not being vacuumed away. > > I have not found the reason that the vacuuming is not as aggressive > as it should be with this old_snapshot_threshold, but I left your > test case running overnight and found that it eventually did kick > in. So the question is why it was not nearly as aggressive as one > would expect.
Once I found it, it turned out to be a bit of a "forehead-slapper". Because the array of entries mapping time to TransactionId was exactly the same size as old_snapshot_threshold, the override of the xmin for pruning or vacuum would not be seen if another transaction got in fast enough, and this python test case was pounding hard enough that the override was rarely seen. By expanding the array by 10 entries, we will only miss the more aggressive cleanup if the thread stalls at that point for more than 10 minutes, which seems like a reasonable degree of patience, given that there is no correctness problem if that does happen. Ants, I think you'll find your test case behaving as you expected now. Now to continue with the performance benchmarks. I'm pretty sure we've fixed the problems when the feature is disabled (old_snapshot_threshold = -1), and there are several suggestions for improving performance while it is on that need to be compared and benchmarked. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers