On Sat, Feb 25, 2017 at 3:40 AM, Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, Feb 24, 2017 at 9:26 AM, Robert Haas <robertmh...@gmail.com> wrote: >> I think this thread is pretty short on evidence that would let us make >> a smart decision about what to do here. I see three possibilities. >> The first is that this patch is a good idea whether we do something >> about the issue of half-dead pages or not. The second is that this >> patch is a good idea if we do something about the issue of half-dead >> pages but a bad idea if we don't. The third is that this patch is a >> bad idea whether or not we do anything about the issue of half-dead >> pages. > > Half-dead pages are not really relevant to this discussion, AFAICT. I > think that both you and Simon mean "recyclable" pages. There are > several levels of indirection involved here, to keep the locking very > granular, so it gets tricky to talk about.
Thanks for the clarification. I wasn't very clear on what was going on here; that helps. The thing that strikes me based on what you wrote is that our page recycling seems to admit of long delays even as things stand. There's no bound on how much time could pass between one index vacuum and the next, and RecentGlobalXmin could and probably usually will advance past the point that would allow recycling long before the next index vacuum cycle. I don't know whether that strengthens or weakens Simon's argument. On the one hand, you could argue that if we're already doing this on a long delay, making it even longer probably won't hurt much. On the other hand, you could argue that if the current situation is bad, we should at least avoid making it worse. I don't know which of those arguments is correct, if either. Do you have an idea about that, or any ideas for experiments we could try? -- Robert Haas EnterpriseDB: 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
