On Wed, 25 Jan 2023 at 19:46, Laurenz Albe <laurenz.albe@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