Yes, see create aggregate for what is required when setting partial aggregation to true. The explanation on [0] (aggregate function reference page) regarding why json creation functions show false is also informative.
Okay, looking at the documentation in depth, it's possible to understand that. The problem is, for a user who only reads this page, and often only the table titled "Partial Mode", what do you want them to understand?
I think it's more reasonable for him to think that Partial refers to filtered data rather than imagining that it is data processed in parallel.
Fair, people do guess when exposed to an unknown technical term instead of searching out its definition. Rename the column to "Parallel Execution?" to avoid that. I agree unless you are writing a new aggregate the exact technical feature name we used is unimportant. Whether it can be totally suppressed here or left to a footnote would need to be decided.
We already cross-reference to the authoritative sections for this. Could entertain a rephrasing of those cross-references but I would not go and make a big thing of it here. That said, maybe a separate “since all aggregates accept a filter clause its syntax has been o tied here for brevity” sentence would work and match up with the existing one for order by.
Why not an introduction for aggregate functions describing not only FILTER but ORDER BY and DISTINCT too ?
agg_function([ DISTINCT ] expression [ , ... ] [ ORDER BY order_by_clause ]) [ FILTER ( WHERE filter_clause ) ])
That is what the syntax chapter covers; though I have had the same thoughts regarding the learn ability of all this. I'd definitely review any proposal to make improvements here. It wouldn't bother me if the consensus was to add some repetition in docs around this.
