On Sat, 13 May 2023 at 06:42, John Naylor <john.nay...@enterprisedb.com> wrote: > > > On Mon, Feb 6, 2023 at 11:04 AM John Naylor <john.nay...@enterprisedb.com> > wrote: > > I'll try to get back to culling the list items at the end of April. > > I've made another pass at this. Previously, I went one or two sections at a > time, but this time I tried just skimming the whole thing and noting what > jumps out at me. Also, I've separated things into three categories: Remove, > move to "not wanted list", and revise. Comments and objections welcome, as > always. > > [...] > -------------------- > 2. Propose to move to the "Not Wanted list": > > (Anything already at the bottom under the heading "Features We Do Not Want", > with the exception of "threads in a single process". I'll just remove that -- > if we ever decide that's worth pursuing, it'll be because we decided we can't > really avoid it anymore, and in that case we surely don't need to put it > here.) > > Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and > CLUSTER > -> There are external tools that help with this kind of analysis
Althrough there are external tools which help with the analysis, the silent complaint of this item seems to be "PostgreSQL doesn't provide the user with actionable maintenance tasks/DDL info", and I wholeheartedly agree with that. Finding out which plans are bad, why they're bad, and how to fix them currently has quite a steep learning curve; and while external tools do help, they are not at all commonly available. The result I got when searching for "automatic postgresql index suggestions" was a combination of hypopg, pg_qualstats and some manual glue to get suggested indexes in the current database - but none of these are available in the main distribution. I'm not asking this to be part of the main PostgreSQL binary, but I don't think that the idea of 'automated suggestions' should be moved to the "not wanted" list - I'd suggest adding it to a list for Contrib instead, if we're insisting on removing it from the main TODO list. Kind regards, Matthias van de Meent PS. note how we already have _some_ suggestions about vacuum and reindex in PostgreSQL, but that is only when things are obviously wrong, and we don't make what I would call intelligent suggestions - in one place we still suggest to shut down the postmaster and then vacuum specific databases in single-user mode.