What you have just seen is a simple aggregate, which has no support for parallel queries and so on. To solve those challenges, the following couple of examples are all about improvements and speedups.

When creating an aggregate, you can optionally define the following things:

[ , PARALLEL = { SAFE  | RESTRICTED | UNSAFE } ] 

By default, an aggregate does not support parallel queries. For performance reasons, it does make sense, however, to explicitly state what the aggregate is capable of:

• UNSAFE: In this mode, no parallel queries are allowed.
• RESTRICTED: In this mode, the aggregate can be executed in parallel mode, but the execution is limited to the parallel group leader.
• SAFE: In this mode, it provides full support for parallel queries.

If you mark a function as SAFE, you have to keep in mind that the function must not have side effects. An execution order must not have an impact on the result of the query. Only then should PostgreSQL be allowed to execute operations in parallel. Examples of functions without side effects would be sin(x) and length(s). The IMMUTABLE functions are good candidates for this since they're guaranteed to return the same result given the same inputs. The STABLE function can work if certain restrictions apply.