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