Alvaro Herrera writes:
> To make matters worse, IIUC it's actually fine to read the cursor in one
> direction to completion, then in the other direction to completion,
> without this flag, right?
In principle that'd be possible without amcanbackward if you were to
shut down the plan at the end of
> "Alvaro" == Alvaro Herrera writes:
>> "Can the scan direction be changed in mid-scan (to support FETCH
>> FORWARD and FETCH BACKWARD on a cursor)?"
How about,
"Can the scan direction be changed in mid-scan (to support FETCH
BACKWARD on a cursor without needing materialization)?"
Alvar
On 2018-May-17, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote:
> >> Maybe "Can the scan direction be reversed in mid-scan?". I'm not
> >> absolutely sure that that's better ...
>
> > A cursory read might conclude that "reversing" can only ha
"David G. Johnston" writes:
> On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote:
>> Maybe "Can the scan direction be reversed in mid-scan?". I'm not
>> absolutely sure that that's better ...
> A cursory read might conclude that "reversing" can only happen once while
> they will likely understand
On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote:
> Andrew Gierth writes:
> > I'll fix the docs accordingly. I'm referring specifically to this bit:
> > https://www.postgresql.org/docs/current/static/functions-
> info.html#FUNCTIONS-INFO-INDEX-PROPS
> > which I think should say "Can the scan dire
Andrew Gierth writes:
> Ugh, so the docs for amutils get this wrong, and if I'd looked at this
> more carefully when doing them to begin with I'd have given the
> 'backwards_scan' property a better name or omitted it entirely.
Ooops.
> I'll fix the docs accordingly. I'm referring specifically to
> "Tom" == Tom Lane writes:
Tom> What amcanbackward is about is whether the index can support
Tom> reversing direction mid-scan, as would be required to support
Tom> FETCH FORWARD followed by FETCH BACKWARD in a cursor. That's
Tom> actually independent of whether the index can implement a
On Wed, May 16, 2018 at 4:54 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Wed, May 16, 2018 at 1:41 AM, Tom Lane wrote:
> >> Perhaps there is a case for adding an additional flag to allow
> specifying
> >> "I can't support ORDER BY DESC", but I'm not in a big hurry to do so.
> >> I t
Alexander Korotkov writes:
> On Wed, May 16, 2018 at 1:41 AM, Tom Lane wrote:
>> Perhaps there is a case for adding an additional flag to allow specifying
>> "I can't support ORDER BY DESC", but I'm not in a big hurry to do so.
>> I think there would be more changes than this needed to handle suc
On Wed, May 16, 2018 at 1:41 AM, Tom Lane wrote:
> Nikita Glukhov writes:
> > Experimenting with the new pluggable storage API, I found that
> amcanbackward
> > flag is not checked in build_index_paths() before
> > build_index_pathkeys(... BackwardScanDirection) call when we are building
> > pat
Nikita Glukhov writes:
> Experimenting with the new pluggable storage API, I found that amcanbackward
> flag is not checked in build_index_paths() before
> build_index_pathkeys(... BackwardScanDirection) call when we are building
> paths for ORDER BY. And this flag is even not copied into IndexOp
11 matches
Mail list logo
