Re: apply_scanjoin_target_to_paths and partitionwise join

Andrei Lepikhov <lepihov@gmail.com>

From: Andrei Lepikhov <lepihov@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, arne.roland@malkut.net, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, Julien Rouhaud <rjuju123@gmail.com>, Etsuro Fujita <etsuro.fujita@gmail.com>, Richard Guo <guofenglinux@gmail.com>
Date: 2024-09-30T21:52:11Z
Lists: pgsql-hackers
On 24/7/2024 15:22, Ashutosh Bapat wrote:
> On Wed, Jul 24, 2024 at 9:42 AM Richard Guo <guofenglinux@gmail.com> wrote:
>> Is there a specific query that demonstrates benefits from this change?
>> I'm curious about scenarios where a partitionwise join runs slower
>> than a non-partitionwise join.
> 
> [1] provides a testcase where a nonpartitionwise join is better than
> partitionwise join. This testcase is derived from a bug reported by an
> EDB customer. [2] is another bug report on psql-bugs.
I haven't passed through the patch yet, but can this issue affect the 
decision on what to push down to foreign servers: a whole join or just a 
scan of two partitions?
If the patch is related to the pushdown decision, I'd say it is quite an 
annoying problem for me. From time to time, I see cases where JOIN 
produces more tuples than both partitions have in total - in this case, 
it would be better to transfer tables' tuples to the main instance 
before joining them.

-- 
regards, Andrei Lepikhov




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove redundant SET enable_partitionwise_join = on.

  2. Don't reset the pathlist of partitioned joinrels.

  3. Allow left join removals and unique joins on partitioned tables

  4. Consider fractional paths in generate_orderedappend_paths

  5. Fix handling of targetlist SRFs when scan/join relation is known empty.