Re: Commitfest 2022-03 Patch Triage Part 1a.i

> On Tue, Mar 01, 2022 at 11:16:36AM -0500, Greg Stark wrote:
> Last November Daniel Gustafsson did a patch triage. It took him three
> emails to get through the patches in the commitfest back then. Since
> then we've had the November and the January commitfests so I was
> interested to see how many of these patches had advanced....
>
> I'm only part way through the first email but so far only two patches
> have changed status -- and both to "Returned with feedback" :(
>
> So I'm going to post updates but I'm going to break it up into smaller
> batches because otherwise it'll take me a month before I post
> anything.

Thanks for being proactive!

> > 1741: Index Skip Scan
> > =====================
> > An often requested feature which has proven hard to reach consensus on an
> > implementation for. The thread(s) have stalled since May, is there any hope of
> > taking this further? Where do we go from here with this patch?
>
> "Often requested indeed! I would love to be able to stop explaining to
> people that Postgres can't handle this case well.
>
> It seems there are multiple patch variants around and suggestions from
> Heikki and Peter G about fundamental interface choices. It would be
> nice to have a good summary from someone who is involved about what's
> actually left unresolved.

I'm going to leave a summary for this one here, if you don't mind.

I believe the design commentary from Heikki about using index_rescan was
more or less answered by Thomas, and having no follow up on that I'm
assuming it was convincing enough.

Peter G most recent suggestion about MDAM approach was interesting, but
very general, not sure what to make of it in absence of any feedback on
follow-up questions/proposed experimental changes.

On top of that a correlated patch [1] that supposed to get some
improvements for this feature on the planner side didn't get much
feedback either. The idea is that the feature could be done in much
better way, but the alternative proposal is still not there and I think
doesn't even have a CF item.

The current state of things is that I've managed to prepare much smaller
and less invasive standalone version of the patch for review, leaving
most questionable parts aside as optional.

Overall it seems that the common agreement about the patch is "the
design could be better", but no one have yet articulated in which way,
or formulated what are the current issues. Having being through 19 CF
the common ground for folks, who were involved into it, is that with no
further feedback the CF item could be closed. Sad but true :(

[1]: https://commitfest.postgresql.org/37/2433/