NoMovementScanDirection
In the context of an index scan, what does NoMovementScanDirection
indicate? On the one hand, relation.h comments:
* 'indexscandir' is one of:
* ForwardScanDirection: forward scan of an ordered index
* BackwardScanDirection: backward scan of an ordered index
* NoMovementScanDirection: scan of an unordered index, or don't care
* (The executor doesn't care whether it gets ForwardScanDirection or
* NoMovementScanDirection for an indexscan, but the planner wants to
* distinguish ordered from unordered indexes for building pathkeys.)
But ExecutorRun() does not invoke ExecutePlan() if the scan direction is
NoMovementScanDirection (and IndexNext() derives its scan direction from
the scan direction that ExecutePlan() sets in the EState). Are there any
situations in which, as the relation.h comment seems to suggest, an
index scan will be invoked with NoMovementScanDirection?
(I ask because gistscancache() is a no-op unless the index scan is
invoked with the NoMovementScanDirection, so it seems of dubious
value...)
-Neil
Neil Conway <neilc@samurai.com> writes:
In the context of an index scan, what does NoMovementScanDirection
indicate?
ScanDirection is used in different ways in different places. The
planner uses NoMovementScanDirection to denote an unordered index scan,
and this propagates into the indxorderdir field of IndexScan plan nodes,
However execMain.c uses NoMovementScanDirection to denote "do nothing",
and so es_direction will never have this value at runtime. I think
pquery.c's use is aligned with the executor but it would take some
closer looking to be completely sure.
Not sure if it's worth factoring the enum type into two (or more?)
types to distinguish these shades of meaning.
regards, tom lane
On Mon, 2004-11-08 at 13:56, Tom Lane wrote:
However execMain.c uses NoMovementScanDirection to denote "do nothing",
and so es_direction will never have this value at runtime.
Ah, okay. I'll remove gistscancache() then, as this seems to be dead
code.
Not sure if it's worth factoring the enum type into two (or more?)
types to distinguish these shades of meaning.
IMHO it would be worth doing.
-Neil
Neil Conway <neilc@samurai.com> writes:
Ah, okay. I'll remove gistscancache() then, as this seems to be dead
code.
Certainly none of the other index types have a concept of caching the
previous tuple like that. I agree, zap it.
regards, tom lane
Tom Lane wrote:
Neil Conway <neilc@samurai.com> writes:
Ah, okay. I'll remove gistscancache() then, as this seems to be dead
code.
Is there someone out there that can instrument the code with Rational
Coverage in order to see how much dead code is still there ? Or at least
see how much code is used during the "make check".
BTW: is there some free tool that do the Rational Coverage work ?
Regards
Gaetano Mendola