On Thu, 9 Jan 2025 at 20:39, Tom Lane wrote:
> Yeah. That prevents pushing down the join condition, since in a FULL join
all
> rows of both sides will contribute to the result; none can be removed
ahead of
> the join.
> Not sure if this pattern is common enough to be worth trying to implement
su
As a followup, these are the `EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)`
plans for the previous version of the query and the one using NOT MATCHED
BY SOURCE.
Previous plan: Buffers: shared hit=84 dirtied=1 written=1
New plan: Buffers: shared hit=100690
*Old plan, using delete in CTE, then M
e Seq Scan expected by others in this mailing list as well?
- Is it required to do the Seq Scan?
- is this something that could be optimized?
Kind regards,
Feike Steenbergen
merge_delete_source_seq_scan_reproduction.sql.s
Description: Binary data
