Re: cutting down the TODO list thread

On Mon, Feb 6, 2023 at 11:04 AM John Naylor <john(dot)naylor(at)enterprisedb(dot)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.

---------------------------------
1. Remove

These are either ill-specified, outdated, possibly done already, or not
enough interest. If someone proposed them again, we could consider it, so I
propose to just remove these, but not move them to the Not Wanted list.
Also some questions:

Improve UTF8 combined character handling?
-> If this is referring to normalization, we have it now. If not, what
needs improving?

Improve COPY performance
-> What's the criterion for declaring this done? There are many areas that
get performance improvements -- why does this need to be called out
separately? (There's been some work in the past couple years, so maybe at
least we need to find out the current bottlenecks.)

Improve line drawing characters
-> This links to a proposal with no responses titled "Add a setting in psql
that set the linestyle to unicode only if the client encoding was actually
UTF8". If we don't drop this, the entry text should at least give an idea
what the proposal is.

Consider improving the continuation prompt
-> A cosmetic proposal that stalled -- time to retire it?

SMP scalability improvements
-> Both threads are from 2007

Consider GnuTLS if OpenSSL license becomes a problem
-> We now have the ability to swap in another implementation during the
build process

Allow creation of universal binaries for Darwin
-> From 2008: Is this still a thing?

Allow plug-in modules to emulate features from other databases
-> This sounds like a hook or extension.

Rethink our type system
-> Way out of scope, and short on details.

Add support for polymorphic arguments and return types to languages other
than PL/PgSQL
-> Seems if someone needed this, they would say so (no thread).

Add support for OUT and INOUT parameters to languages other than PL/PgSQL
-> Ditto

--------------------
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

Allow regex operations in PL/Perl using UTF8 characters in non-UTF8 encoded
databases
-> Seems pie-in-the-sky as well as a niche problem?

Add option to print advice for people familiar with other databases
-> Doesn't seem relevant anymore?

Consider having single-page pruning update the visibility map
-> Comment from Heikki in the thread:
"I think I was worried about the possible performance impact of having to
clear the bit in visibility map again. If you're frequently updating a
tuple so that HOT and page pruning is helping you, setting the bit in
visibility map seems counter-productive; it's going to be cleared soon
again by another UPDATE. That's just a hunch, though. Maybe the overhead
is negligible."

Consider mmap()'ing entire files into a backend?
-> Isn't this a can of worms?

Consider allowing control of upper/lower case folding of unquoted
identifiers
-> Would we ever consider this?

---------------------------------
Other -- need adjustment or update?

Do async I/O for faster random read-ahead of data
-> This section needs to be revised, since there is on-going work on AIO.
There are a couple other entries that should maybe be put under a different
heading?

*** The whole section on Windows has lots of old stuff -- which are still
relevant?

(ECPG) Fix nested C comments
-> What needs fixing? It should work fine.

Improve speed of tab completion
-> Is this still a problem?

Testing pgstat via pg_regress is tricky and inefficient. Consider making a
dedicated pgstat test-suite.
-> This has significantly changed recently -- how are things now?

--
John Naylor
EDB: http://www.enterprisedb.com