I've now pushed up v8-0004. Can rebase the remaining 2 patches on top of master again and resend?
On Mon, 3 Apr 2023 at 08:11, Melanie Plageman <melanieplage...@gmail.com> wrote: > I still have a few open questions: > - what the initial value of ring_size for autovacuum should be (see the > one remaining TODO in the code) I assume you're talking about the 256KB BAS_VACUUM one set in GetAccessStrategy()? I don't think this patch should be doing anything to change those defaults. Anything that does that should likely have a new thread and come with analysis or reasoning about why the newly proposed defaults are better than the old ones. > - should ANALYZE allow specifying BUFFER_USAGE_LIMIT since it uses the guc > value when that is set? That's a good question... > - should INDEX_CLEANUP off cause VACUUM to use shared buffers and > disable use of a strategy (like failsafe vacuum) I don't see why it should. It seems strange to have one option magically make changes to some other option. > - should we add anything to VACUUM VERBOSE output about the number of > reuses of strategy buffers? Sounds like this would require an extra array of counter variables in BufferAccessStrategyData? I think it might be a bit late to start experimenting with this. > - Should we make BufferAccessStrategyData non-opaque so that we don't > have to add a getter for nbuffers. I could have implemented this in > another way, but I don't really see why BufferAccessStrategyData > should be opaque If nothing outside of the .c file requires access then there's little need to make the members known outside of the file. Same as you'd want to make classes private rather than public when possible in OOP. If you do come up with a reason to be able to determine the size of the BufferAccessStrategy from outside freelist.c, I'd say an accessor method is the best way. David David
