Difference between revisions of "PostgreSQL 13 Open Items"

From PostgreSQL wiki
Jump to: navigation, search
(Mark EXPLAIN ANALYZE output for HashAgg not being similar enough to Hash Join as complete.)
(Close out "Many users rely on hashagg exceeding work_mem, regardless of whether or not that is the intended behavior in Postgres 12")
(2 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
'''NOTE''': Please place new open items at the end of the list.
 
'''NOTE''': Please place new open items at the end of the list.
 
* [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]
 
** When these users don't continue to get fast in-memory hash aggs after an upgrade to Postgres 13, they'll simply conclude that it's a regression.
 
** 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.
 
** 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://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 22: Line 16:
 
=== Live issues ===
 
=== Live issues ===
  
* [https://www.postgresql.org/message-id/20200728151002.GE20393%40telsasoft.com ItemPointer values should never be equal]
+
* [https://www.postgresql.org/message-id/20200728151002.GE20393%40telsasoft.com ItemPointer values should never be equal in an index]
 +
** Apparently system catalog index builds can sometimes create an index that breaks the HOT invariant by having two index tuples with the same identical heap TID value.
 
** Affects all stable branches
 
** Affects all stable branches
  
Line 65: Line 60:
  
 
* [https://www.postgresql.org/message-id/20200415233848.saqp72pcjv2y6ryi%40alap3.anarazel.de xid wraparound danger due to INDEX_CLEANUP false.]
 
* [https://www.postgresql.org/message-id/20200415233848.saqp72pcjv2y6ryi%40alap3.anarazel.de xid wraparound danger due to INDEX_CLEANUP false.]
** Affects v12
+
** Affects v12+
 
** This bug [https://www.postgresql.org/message-id/CA+TgmoYD7Xpr1DWEWWXxiw4-WC1NBJf3Rb9D2QGpVYH9ejz9fA@mail.gmail.com will not be fixed] in v13 or other backbranches.
 
** This bug [https://www.postgresql.org/message-id/CA+TgmoYD7Xpr1DWEWWXxiw4-WC1NBJf3Rb9D2QGpVYH9ejz9fA@mail.gmail.com will not be fixed] in v13 or other backbranches.
 
** Maybe it can be fixed by future work that makes B-Tree page recycling work at the tail end of the same VACUUM operation that initially deletes the pages, but that's out of scope for now.
 
** Maybe it can be fixed by future work that makes B-Tree page recycling work at the tail end of the same VACUUM operation that initially deletes the pages, but that's out of scope for now.
Line 74: Line 69:
  
 
=== resolved before 13beta3 ===
 
=== resolved before 13beta3 ===
 +
 +
* [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]
 +
** When these users don't continue to get fast in-memory hash aggs after an upgrade to Postgres 13, they'll simply conclude that it's a regression.
 +
** Increasing work_mem isn't usually an option, since that affects everything equally.
 +
** We decided to ameliorate problem using the new hash_mem_multiplier GUC, which allows users to preferentially give hash-based executor nodes more memory.
 +
** Hopefully it won't also prove necessary to add an escape hatch. In any case this isn't the final word.
 +
** Owner: Peter Geoghegan
 +
** Fixed at: {{PgCommitURL|d6c08e29e7bc8bc3bf49764192c4a9c71fc0b097}}
  
 
* [https://postgr.es/m/9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com Default setting for hashagg_avoid_disk_plan GUC]
 
* [https://postgr.es/m/9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com Default setting for hashagg_avoid_disk_plan GUC]

Revision as of 21:26, 29 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