>>>>> "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)