On Wed, 25 Jan 2023 at 19:46, Laurenz Albe <laurenz.a...@cybertec.at> wrote: > Did you see Justin's wording suggestion in > https://postgr.es/m/20230118174919.GA9837%40telsasoft.com ? > He didn't attach it as a patch, so you may have missed it. > I was pretty happy with that.
I didn't pay too much attention as I tend to apply patches to obtain the full context of the change. Manually trying to apply a patch from an email is not something I like to do. > I think your first sentence it a bit clumsy and might be streamlined to > > Partitioned tables do not directly store tuples and consequently do not > require autovacuum to perform any <command>VACUUM</command> operations. That seems better than what I had. > Also, I am a little bit unhappy about > > 1. Your paragraph states that partitioned table need no autovacuum, > but doesn't state unmistakably that they will never be treated > by autovacuum. hmm. I assume the reader realises from the text that lack of any tuples means VACUUM is not required. The remaining part of what autovacuum does not do is explained when the text goes on to say that ANALYZE operations are also not performed on partitioned tables. I'm not sure what is left that's mistakable there. > 2. You make a distinction between table partitions and "normal tables", > but really there is no distiction. We may have different mental models here. This relates to the part that I wasn't keen on in your patch, i.e: + The partitions of a partitioned table are normal tables and get processed + by autovacuum While I agree that the majority of partitions are likely to be relkind='r', which you might ordinarily consider a "normal table", you just might change your mind when you try to INSERT or UPDATE records that would violate the partition constraint. Some partitions might also be themselves partitioned tables and others might be foreign tables. That does not really matter much when it comes to what autovacuum does or does not do, but I'm not really keen to imply in our documents that partitions are "normal tables". David