On Thu, Apr 22, 2021 at 4:52 PM Peter Geoghegan <p...@bowt.ie> wrote: > Mostly what I'm saying is that I would like to put together a rough > list of things that we could do to improve VACUUM along the lines > we've discussed -- all of which stem from $SUBJECT. There are > literally dozens of goals (some of which are quite disparate) that we > could conceivably set out to pursue under the banner of $SUBJECT.
I hope not. I don't have a clue why there would be dozens of possible goals here, or why it matters. I think if we're going to do something like $SUBJECT, we should just concentrate on the best way to make that particular change happen with minimal change to anything else. Otherwise, we risk conflating this engineering effort with others that really should be separate endeavors. For example, as far as possible, I think it would be best to try to do this without changing the statistics that are currently gathered, and just make the best decisions we can with the information we already have. Ideally, I'd like to avoid introducing a new kind of relation fork that uses a different on-disk storage format (e.g. 16MB segments that are dropped from the tail) rather than the one used by the other forks, but I'm not sure we can get away with that, because conveyor-belt storage looks pretty appealing here. Regardless, the more we have to change to accomplish the immediate goal, the more likely we are to introduce instability into places where it could have been avoided, or to get tangled up in endless bikeshedding. -- Robert Haas EDB: http://www.enterprisedb.com
