Difference between revisions of "PostgreSQL 13 Open Items"

From PostgreSQL wiki
Jump to: navigation, search
(Close LookupTupleHashEntryHash() pipeline stall issue)
(resolved before 13beta3)
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Open Issues ==
 
== Open Issues ==
  
'''NOTE''': Please place new open items at the end of the list (within its applicable open item category).
+
'''NOTE''': Please place new open items at the end of the list.
 
 
=== Hash Aggs that spill (commit 1f39bce0) issues ===
 
  
 
* [https://www.postgresql.org/message-id/20200625203629.7m6yvut7eqblgmfo@alap3.anarazel.de Many users rely on hashagg exceeding work_mem, regardless of whether or not that is the intended behavior in Postgres 12]
 
* [https://www.postgresql.org/message-id/20200625203629.7m6yvut7eqblgmfo@alap3.anarazel.de Many users rely on hashagg exceeding work_mem, regardless of whether or not that is the intended behavior in Postgres 12]
Line 9: Line 7:
 
** Increasing work_mem isn't usually an option, since that affects everything equally.
 
** Increasing work_mem isn't usually an option, since that affects everything equally.
 
** There are good general reasons to preferentially give hash aggregate more memory than a sort used for a group aggregate, so these users will certainly have a point if this happens.
 
** There are good general reasons to preferentially give hash aggregate more memory than a sort used for a group aggregate, so these users will certainly have a point if this happens.
** We have a pending [https://www.postgresql.org/message-id/CAH2-Wz=YP4UcJwCLx51W47o95fh2nCYdFLtamv7nUmRch9+mrg@mail.gmail.com hash_mem_multiplier patch] which proposes to solve this issue in an indirect way.
+
** We have a pending [https://www.postgresql.org/message-id/CAH2-Wz=YP4UcJwCLx51W47o95fh2nCYdFLtamv7nUmRch9+mrg@mail.gmail.com hash_mem_multiplier patch] which ameliorates the risk in an indirect way.
 
 
* [https://postgr.es/m/9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com Default setting for hashagg_avoid_disk_plan GUC] (the GUC formerly known as enable_hashagg_disk, renamed by {{PgCommitURL|92c58fd9}})
 
** This thread is [https://postgr.es/m/CAH2-WzmD+i1pG6rc1+Cjc4V6EaFJ_qSuKCCHVnH=oruqD-zqow@mail.gmail.com 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 [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/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]
 
** "despite writing about twice as much data, the hashagg cost is estimated to be much lower than the sort".
 
** "despite writing about twice as much data, the hashagg cost is estimated to be much lower than the sort".
 
** At the very low end, the amount of I/O performed by hash aggregate can significantly exceed what we see with the equivalent Group agg + sort.
 
** At the very low end, the amount of I/O performed by hash aggregate can significantly exceed what we see with the equivalent Group agg + sort.
 
=== Other issues ===
 
  
 
* [https://www.postgresql.org/message-id/20200619040358.GZ17995@telsasoft.com EXPLAIN ANALYZE's non-text output should consistently include all fields for incremental sort, meaning fields "not applicable" to text format output should be shown as 0]
 
* [https://www.postgresql.org/message-id/20200619040358.GZ17995@telsasoft.com EXPLAIN ANALYZE's non-text output should consistently include all fields for incremental sort, meaning fields "not applicable" to text format output should be shown as 0]
Line 85: Line 74:
  
 
=== resolved before 13beta3 ===
 
=== resolved before 13beta3 ===
 +
 +
* [https://postgr.es/m/9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com Default setting for hashagg_avoid_disk_plan GUC]
 +
** hashagg_avoid_disk_plan GUC preserves the plan time behavior from Postgres 12, but not the execution time behavior.
 +
** We decided to remove the GUC altogether.
 +
** Owner: Peter Geoghegan
 +
** Fixed at: {{PgCommitURL|bcbf9446a2983b6452c19cc50050456be262f7c5}}
  
 
* [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]
 
* [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]

Revision as of 01:27, 28 July 2020

Open Issues

NOTE: Please place new open items at the end of the list.

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