Re: BUG #16536: Segfault with partition-wise joins

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> Anyway, I can see a couple of routes to a fix:

 Tom> (1) Change create_bitmap_and_path and create_bitmap_or_path to
 Tom> account for parameterization honestly. This is certainly the
 Tom> cleanest fix, but it would add some cycles, and what's probably a
 Tom> bigger issue for back-patching is that their signatures would have
 Tom> to change. Maybe that's okay? There's probably not a reason for
 Tom> external code to call them, and codesearch.debian.net knows of no
 Tom> instances of that.

 Tom> (2) Hack up reparameterize_path_by_child so that it will descend
 Tom> into these nodes regardless of their parameterization markers.
 Tom> That's okay from an efficiency standpoint, since we'd already have
 Tom> stopped at the parent BitmapHeapPath if it weren't parameterized.
 Tom> But it seems quite ugly.

Well the obvious compromise fix is to do 2 in the back-branches and 1 in
head, but that may be overkill...

 Tom> Another point I notice is that reparameterize_path thinks it
 Tom> doesn't need to touch sub-structure at all when increasing the
 Tom> parameterization of a BitmapHeapPath. Maybe that's okay but it
 Tom> probably deserves more thought, especially since I see that the
 Tom> case is again untested.

Hmm. I'm not sure I fully understand the implications of what's going on
there, but if new quals are effectively being moved into the path as a
result of the reparameterization, then leaving the substructure alone
would presumably mean that those new quals can only become Filter:
clauses. But presumably, if they could be usefully indexed, then we
would have already generated a parameterized path that included them?

-- 
Andrew (irc:RhodiumToad)