Re: cutting down the TODO list thread - Mailing list pgsql-hackers

On Sat, 13 May 2023 at 06:42, John Naylor <john.naylor@enterprisedb.com> wrote:
>
>
> On Mon, Feb 6, 2023 at 11:04 AM John Naylor <john.naylor@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
thewhole thing and noting what jumps out at me. Also, I've separated things into three categories: Remove, move to "not
wantedlist", 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
singleprocess". I'll just remove that -- if we ever decide that's worth pursuing, it'll be because we decided we can't
reallyavoid 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.