Re: [HACKERS] NoMovementScanDirection in heapgettup() and heapgettup_pagemode()

[Mithun Cy]

On Mon, Aug 28, 2017 at 5:50 PM, Tom Lane  wrote:
> I think that's probably dead code given that ExecutorRun short-circuits
> everything for NoMovementScanDirection.  There is some use of
> NoMovementScanDirection for indexscans, to denote an unordered index,
> but likely that could be got rid of too.  That would leave us with
> NoMovementScanDirection having no other use except as a do-nothing
> flag for ExecutorRun.
>
> regards, tom lane

Thanks, Tom, yes it seems to be a dead code.

-- 
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] NoMovementScanDirection in heapgettup() and heapgettup_pagemode()

[Tom Lane]

Mithun Cy  writes:
> I was trying to study NoMovementScanDirection part of heapgettup() and
> heapgettup_pagemode(). If I am right there is no test in test suit to
> hit this code. I did run make check-world could not hit it. Also,
> coverage report in
> https://coverage.postgresql.org/src/backend/access/heap/heapam.c.gcov.html
> shows this part of the code is not hit. Can somebody please help me to
> understand this part of the code and how to test same?

I think that's probably dead code given that ExecutorRun short-circuits
everything for NoMovementScanDirection.  There is some use of
NoMovementScanDirection for indexscans, to denote an unordered index,
but likely that could be got rid of too.  That would leave us with
NoMovementScanDirection having no other use except as a do-nothing
flag for ExecutorRun.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] NoMovementScanDirection in heapgettup() and heapgettup_pagemode()

[Mithun Cy]

Hi all,
I was trying to study NoMovementScanDirection part of heapgettup() and
heapgettup_pagemode(). If I am right there is no test in test suit to
hit this code. I did run make check-world could not hit it. Also,
coverage report in
https://coverage.postgresql.org/src/backend/access/heap/heapam.c.gcov.html
shows this part of the code is not hit. Can somebody please help me to
understand this part of the code and how to test same?

-- 
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] NoMovementScanDirection

[Gaetano Mendola]

Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] NoMovementScanDirection

[Neil Conway]

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



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] NoMovementScanDirection

[Neil Conway]

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



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] NoMovementScanDirection

[Tom Lane]

Neil Conway [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] NoMovementScanDirection

[Tom Lane]

Neil Conway [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])