Difference between revisions of "PostgreSQL 13 Open Items"

From PostgreSQL wiki
Jump to: navigation, search
(Open Issues: Added item about unnecessary variations between Hash Agg and Hash Join EXPLAIN ANALYZE output)
(Close LookupTupleHashEntryHash() pipeline stall issue)
Line 17: Line 17:
 
** In theory there should be no difference (in theory these two open items are one and the same). In practice there is a huge difference, because group estimates are frequently off by orders of magnitude, and because hash aggs greatly benefit from more memory (unlike the equivalent group aggregate + sort plan).
 
** In theory there should be no difference (in theory these two open items are one and the same). In practice there is a huge difference, because group estimates are frequently off by orders of magnitude, and because hash aggs greatly benefit from more memory (unlike the equivalent group aggregate + sort plan).
 
** We have a pending [https://www.postgresql.org/message-id/CAH2-Wz=YP4UcJwCLx51W47o95fh2nCYdFLtamv7nUmRch9+mrg@mail.gmail.com patch] that removes the hashagg_avoid_disk_plan GUC (which is part of a patch series that also adds the hash_mem_multiplier GUC).
 
** We have a pending [https://www.postgresql.org/message-id/CAH2-Wz=YP4UcJwCLx51W47o95fh2nCYdFLtamv7nUmRch9+mrg@mail.gmail.com patch] that removes the hashagg_avoid_disk_plan GUC (which is part of a patch series that also adds the hash_mem_multiplier GUC).
 
* [https://www.postgresql.org/message-id/20200612213715.op4ye4q7gktqvpuo%40alap3.anarazel.de HashAggs-that-spill patch introduced a perf regression affecting classic in-memory HashAggs: LookupTupleHashEntryHash() pipeline stall]
 
** Note that {{PgCommitURL|4cad2534}} was reverted already (by {{PgCommitURL|0babd109}}, which anticipated {{PgCommitURL|23023022}}), but that alone isn't enough.
 
** A patch that fixes the issue [https://www.postgresql.org/message-id/CAH2-Wzne5FQ31XaQz_-qJ_fTfc_NvwdTyT7BdqESvGnftmCsfw@mail.gmail.com is available].
 
** This is [https://www.postgresql.org/message-id/20200724235114.xy4a2egntf7y7djh@alap3.anarazel.de still not fixed] in late July -- this presumably complicates resolving all the other hash agg open items, since we don't have a representative Postgres 13 baseline for in-memory hash agg performance.
 
  
 
* [https://www.postgresql.org/message-id/20200724012248.y77rpqc73agrsvb3@development HashAggs-that-spill costing seems off in cases where we spill and work_mem is far below the "optimal" amount for the aggregate]
 
* [https://www.postgresql.org/message-id/20200724012248.y77rpqc73agrsvb3@development HashAggs-that-spill costing seems off in cases where we spill and work_mem is far below the "optimal" amount for the aggregate]
Line 90: Line 85:
  
 
=== resolved before 13beta3 ===
 
=== resolved before 13beta3 ===
 +
 +
* [https://www.postgresql.org/message-id/20200612213715.op4ye4q7gktqvpuo%40alap3.anarazel.de HashAggs-that-spill patch introduced a perf regression affecting classic in-memory HashAggs: LookupTupleHashEntryHash() pipeline stall]
 +
** Original commit: {{PgCommitURL|1f39bce0}}
 +
** Owner: Jeff Davis
 +
** Fixed at: {{PgCommitURL|200f6100a9f9fc71273aeb6aceac4430f3437195}}
  
 
* [https://www.postgresql.org/message-id/flat/2edc7b27-031f-b2b6-0db2-864241c91cb9%402ndquadrant.com Output columns shown by new \dAo and \dAp psql commands are arguably confusing, inconsistent]
 
* [https://www.postgresql.org/message-id/flat/2edc7b27-031f-b2b6-0db2-864241c91cb9%402ndquadrant.com Output columns shown by new \dAo and \dAp psql commands are arguably confusing, inconsistent]

Revision as of 02:01, 27 July 2020

Open Issues

NOTE: Please place new open items at the end of the list (within its applicable open item category).

Hash Aggs that spill (commit 1f39bce0) issues

  • Default setting for hashagg_avoid_disk_plan GUC (the GUC formerly known as enable_hashagg_disk, renamed by 92c58fd9)
    • This thread is now mostly a discussion of the preceding "Many users rely on hashagg exceeding work_mem, regardless of whether or not that is the intended behavior in Postgres 12" item.
    • You can think of this hashagg_avoid_disk_plan item as being about providing users with a mechanism to avoid hash aggregation when planning, without reliably ensuring that it is avoided at execution time.
    • In other words, it preserves the plan time behavior from Postgres 12, but not the execution time behavior.
    • In theory there should be no difference (in theory these two open items are one and the same). In practice there is a huge difference, because group estimates are frequently off by orders of magnitude, and because hash aggs greatly benefit from more memory (unlike the equivalent group aggregate + sort plan).
    • We have a pending patch that removes the hashagg_avoid_disk_plan GUC (which is part of a patch series that also adds the hash_mem_multiplier GUC).

Other issues

Older Bugs

Live issues

Fixed issues

Nothing to do

Non-bugs

Resolved Issues

resolved before 13beta3

  • Review the decision to enable deduplication by default (i.e. use 'on' as the default setting for the 'deduplicate_items' B-Tree storage parameter).

resolved before 13beta2

  • Should we rename effective_io_concurrency? It now has a different meaning and you might want to turn it up higher, though the default behaviour hasn't changed.
    • Commit: b09ff536
    • No one argued strongly in favour of changing it, so let's leave it as it is.

resolved before 13beta1

Won't Fix

Important Dates

Current schedule:

  • Feature Freeze: April 7, 2020 (Last Day to Commit Features)
  • Beta 1: May 21, 2020
  • Beta 2: June 25, 2020
  • Beta 3: August 13, 2020