User:Andresfreund/Desired Changes
From PostgreSQL wiki
Jump to navigationJump to search
This page shows changes that I'd like to see in postgres, but that I am not personally working on at this point. Please feel free to work on any of these.
Stats
System View showing TCP statistics
- This would be useful to debug things like replication not keeping up, which is often caused by TCP settings. The statistics should show information as shown by the the ss utility. While ss provides the necessary information, it makes it too hard to combine the information with postgres information (like which connections are for replication etc).
System View showing OS memory usage
- Currently it is very hard to know from within postgres which process actually uses how much memory. We should use operating system stats to show that information on operating systems where we know how.
Add information about the number of newly created WAL segments to log_checkpoints output
- While log_checkpoint output already includes information about added WAL segments, that information does not include WAL segments created by backends, making the number extremely misleading.
System view showing what is holding back the xmin horizon
- Today it takes a lot of knowledge to find all potential sources of holding back the xmin horizon. We should have a view showing all the sources of the horizon being held back.
Benchmarking
pgbench throttling with uniform distribution
- The current Poisson distribution that pgbench -R uses adds so much noise that it's basically impossible to see changes in server latency
pgbench setup steps as part of custom scripts
- currently it's not possible to have distribute a single pgbench script that supports initializing the workload and running the benchmark as a single file
Features
Introduce shared state for open relations
-
This is an enabling feature for many things:
- AIO safe sync request queue (AIO needs to register dirty segments while in crit section)
- safe caching of relation sizes, instead of constantly doing fstats
- autovacuum partial trunctions without needing an AccessExclusiveLock (which causes query cancellations on standbys)
- a more efficient buffer mapping would use a radix tree per relation, which in turn requires a place to "hang off" the radix tree
Ensure that shared memory is populated at server start
- Currently all shared memory is only actually allocated the first time memory is touched. That means that workloads have a prolonged warmup period until steady performance is reached.
Add functionality to pre-allocate WAL segments
- Performance of postgres changes wildly depending on whether WAL files are newly created or recycled (with the latter being much better on non-COW filesystems). We should provide a function to pre-create WAL segments.
Functions for getting block number / offset from a TID
- I've way too many times written a regex to get block numbers out of tids. We should just have SQL level accessors.
Lightweight memory contexts
- For things like relcache entries, it'd be rather desirable to use fine-grained memory contexts, but using a full memory context would be rather heavyweight. We should create a new memory context type that does allocations using malloc() and tracks them in a linked list. That would obviously be a bit slower, but uses cases for it should never be heavy on allocations. We could also "promote" such contexts once the number of allocations increases.
Make MemoryContext code usable in frontend code
- Lots of frontend code would like to share code with backend code, including use of memory contexts. There are also complicated frontend binaries that could benefit from memory contexts.
Split PANIC log level into failures that should dump core and ones that don't
- Lots of reasons for PANIC do not benefit of a core file being generated. E.g. a PANIC due to ENOSPC during WAL file creation just makes the problem worse.
Allow startup process to report errors that do not trigger a postmaster crash-restart cycle
- There are errors detected by the startup process that will not be resolved by a crash-restart cycle, yet we react to them being thrown by doing a crash-restart cycle.