Horton
Menu

Re: apply_scanjoin_target_to_paths and partitionwise join

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Arne Roland <arne.roland@malkut.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Andrei Lepikhov <lepihov@gmail.com>, Jakub Wartak <jakub.wartak@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Julien Rouhaud <rjuju123@gmail.com>, Etsuro Fujita <etsuro.fujita@gmail.com>, Richard Guo <guofenglinux@gmail.com>
Date: 2025-10-29T18:55:21Z
Lists: pgsql-hackers 
On Wed, Oct 29, 2025 at 2:06 PM Arne Roland <arne.roland@malkut.net> wrote:
> This virtually equivalent query issue occurs when the join condition is
> (almost) unique. The different amount of tuples to process clearly
> occurs when they are not.

I'm having trouble interpreting this. If it's important, please
clarify and show an example.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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.