Since commit
f0f13a3a08b2757997410f3a1c38bdc22973c525, we estimate
ModifyTable paths without a RETURNING clause differently. Update an
example from the manual that showed the old behavior.
Author: Takayuki Tsunakawa <tsunakawa.takay@fujitsu.com>
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>
Discussion: https://postgr.es/m/TYAPR01MB29905674F41693BBA9DA28CAFEA20%40TYAPR01MB2990.jpnprd01.prod.outlook.com
QUERY PLAN
-------------------------------------------------------------------&zwsp;-------------------------------------------------------------
- Update on tenk1 (cost=5.07..229.46 rows=101 width=250) (actual time=14.628..14.628 rows=0 loops=1)
+ Update on tenk1 (cost=5.07..229.46 rows=0 width=0) (actual time=14.628..14.628 rows=0 loops=1)
-> Bitmap Heap Scan on tenk1 (cost=5.07..229.46 rows=101 width=250) (actual time=0.101..0.439 rows=100 loops=1)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.043..0.043 rows=100 loops=1)
EXPLAIN UPDATE parent SET f2 = f2 + 1 WHERE f1 = 101;
QUERY PLAN
-------------------------------------------------------------------&zwsp;----------------
- Update on parent (cost=0.00..24.53 rows=4 width=14)
+ Update on parent (cost=0.00..24.53 rows=0 width=0)
Update on parent
Update on child1
Update on child2