On Fri, Jul 15, 2022 at 07:27:47PM -0400, Jonathan S. Katz wrote:
> > So I agree with Andres here. It seems weird to me to try to document
> > this new thing that I caused when we don't really make any attempt to
> > document all the other weird stuff with work_mem.
>
> I can't argue with this.
>
> My note on the documentation was primarily around to seeing countless user
> issues post-upgrade where queries that "once performed well no longer do
> so." I want to ensure that our users at least have a starting point to work
> on resolving the issues, even if they end up being very nuanced.
>
> Perhaps a next step (and a separate step from this) is to assess the
> guidance we give on the upgrade page[1] about some common things they should
> check for. Then we can have the "boilerplate" there.
I assume that if you set a GUC, you should also review and maintain it into the
future. Non-default settings should be re-evaluated (at least) during major
upgrades. That's typically more important than additionally fidding with any
newly-added GUCs.
For example, in v13, I specifically re-evaluated shared_buffers everywhere due
to de-duplication.
In v13, hash agg was updated to spill to disk, and hash_mem_multiplier was
added to mitigate any performance issues (and documented as such in the release
notes).
I've needed to disable JIT since it was enabled by default in v12, since it
1) doesn't help; and 2) leaks memory enough to cause some customers' DBs to be
killed every 1-2 days. (The change in default was documented, so there's no
more documentation needed).
I'm sure some people should/have variously revisted the parallel and
"asynchronous" GUCs, if they changed the defaults. (When parallel query was
enabled by default in v10, the change wasn't initially documented, which was a
problem).
I'm suppose checkpoint_* and *wal* should be/have been revisited at various
points. Probably effective_cache_size too. Those are just the most common
ones to change.
--
Justin