> On Tue, Feb 04, 2020 at 08:34:09PM +0000, Floris Van Nee wrote: > > > this point me and Jesper inclined to go with the second option. But maybe > > I'm missing something, are there any other suggestions? > > Unfortunately I figured this would need a more invasive fix. I tend to agree > that it'd be better to not skip in situations like this. I think it'd make > most sense to make any plan for these 'prepare/fetch' queries would not use > skip, but rather a materialize node, right?
Yes, sort of, without a skip scan it would be just an index only scan with unique on top. Actually it's not immediately clean how to achieve this, since at the moment, when planner is deciding to consider index skip scan, there is no information about neither direction nor whether we're dealing with a cursor. Maybe we can somehow signal to the decision logic that the root was a DeclareCursorStmt by e.g. introducing a new field to the query structure (or abusing an existing one, since DeclareCursorStmt is being processed by standard_ProcessUtility, just for a test I've tried to use utilityStmt of a nested statement hoping that it's unused and it didn't break tests yet).
