I came here to talk about partitionwise join, but then noticed you have
already thought of that:
On 2023-Jun-18, nicolas paris wrote:
> Note that both plan acome from the same partitioned by hash table with
> 100 parts, with a unique index on the list_id + hash_key. For strategy
> 2.1, I turned on enable_partitionwise_join, since david table has the
> same partitioning scheme as goliath including unique indexe. In both
> case the query is:
Hmm, I suppose the reason partitionwise join isn't having any effect is
that the presence of WHEN NOT MATCHED clauses force an outer join, which
probably disarms partitionwise joining, since each join pair would
require to match for nulls, so there would be two matching partitions at
the other end. A quick test for this hypothesis might be to try the
MERGE without the WHEN NOT MATCHED clauses and see if partitionwise join
works better.
Maybe Tom L's new outer-join infrastructure in 16 allows to improve on
this, not sure.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Los dioses no protegen a los insensatos. Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)