FAQ
Hi,

Query:
=====
I am aware of the fact that Expression evaluator is used to filter tuples
based on the qual. However, I think it is not the only purpose it serves. As
I manipulated the ExecEvalVar in the executor, the queries started behaving
abnormally (the comparison operators < , <>, > lost effect and at times
started working ). Is the creation of qual also done (in part?) by the
expression evaluator? If yes, what part of query creation process is handled
by the evaluator? I know ExecInitExpr does expr -> exprstate tree creation,
but it is not the evaluator.

If the above is confusing, I just want to ask: "Is expression evaluator,
even in part responsible for {PLANNEDSTMT creation?"
--------------------------------------------------------


My work / trial so far:
===============
I see that the target list to be scanned is handled by "ExecTargetList"
function.

I am not so sure about this because this function is not listed in the list
of functions which GDB shows me (./configure --enable-debug && make clean &&
make && make install). Rest everything else (almost / perhaps) is shown!
(Can anyone tell why? :( )

Whatever be the case, I think the target list creation will somehow call
ExecEvalVar because:

1. It is this function whose modification gets me the erroneous behavior.
2. Server, when run in debug 4 / 5 mode shows target entries as VARs.
3. VARs are range table representation in some form and ExecEvalVar makes
sense to create the target entry.
---------------------------------------------------


What changes caused this:
===================

I inserted this line into ExecEvalVar as well as ExecEvalScalarVar:

return cute_datum_array[attnum];

before:

return slot_getattr(slot, attnum, isNull);

It was just an experiment to see how things are getting done. I know most
devs here would suggest GDB but I am already using that and I did this to
check possible effects than trace.

-----------------------------------------------------

I seriously think the target list would involve VARs whose one-time
evaluation is done. Since cute_datum_array was a garbage array
(intentional), it would crash! Am I right?

Regards,
Vaibhav

Search Discussions

  • Pavan Deolasee at May 25, 2011 at 10:03 am

    On Wed, May 25, 2011 at 3:22 PM, Vaibhav Kaushal wrote:

    I see that the target list to be scanned is handled by "ExecTargetList"
    function.

    I am not so sure about this because this function is not listed in the list
    of functions which GDB shows me (./configure --enable-debug && make clean &&
    make && make install). Rest everything else (almost / perhaps) is shown!
    (Can anyone tell why? :( )
    You would need to turn optimization off by passing "-O0" flag to the
    compiler. Otherwise static functions may get optimized and you may not see
    them in gdb stack.

    CFLAGS="-O0" ./configure --enable-debug

    Thanks,
    Pavan

    --
    Pavan Deolasee
    EnterpriseDB http://www.enterprisedb.com
  • Vaibhav Kaushal at May 25, 2011 at 4:43 pm
    @pavan - thanks a lot. Will try it when i go to desktop the next time.

    --
    Sent from my Android
    On 25 May 2011 15:33, "Pavan Deolasee" wrote:
    On Wed, May 25, 2011 at 3:22 PM, Vaibhav Kaushal <
    vaibhavkaushal123@gmail.com> wrote:
    I see that the target list to be scanned is handled by "ExecTargetList"
    function.

    I am not so sure about this because this function is not listed in the
    list
    of functions which GDB shows me (./configure --enable-debug && make clean
    &&
    make && make install). Rest everything else (almost / perhaps) is shown!
    (Can anyone tell why? :( )
    You would need to turn optimization off by passing "-O0" flag to the
    compiler. Otherwise static functions may get optimized and you may not see
    them in gdb stack.

    CFLAGS="-O0" ./configure --enable-debug

    Thanks,
    Pavan

    --
    Pavan Deolasee
    EnterpriseDB http://www.enterprisedb.com
  • Alvaro Herrera at May 25, 2011 at 2:58 pm

    Excerpts from Vaibhav Kaushal's message of mié may 25 05:52:32 -0400 2011:

    If the above is confusing, I just want to ask: "Is expression evaluator,
    even in part responsible for {PLANNEDSTMT creation?"
    Yeah, as far as I understood Tom's talk, the expr evaluator is used to
    reduce some expressions to constants and such.

    --
    Álvaro Herrera <alvherre@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Tom Lane at May 25, 2011 at 3:41 pm

    Alvaro Herrera writes:
    Excerpts from Vaibhav Kaushal's message of mié may 25 05:52:32 -0400 2011:
    If the above is confusing, I just want to ask: "Is expression evaluator,
    even in part responsible for {PLANNEDSTMT creation?"
    Yeah, as far as I understood Tom's talk, the expr evaluator is used to
    reduce some expressions to constants and such.
    The planner would never call it with an expression containing a Var,
    though.

    regards, tom lane
  • Vaibhav Kaushal at May 25, 2011 at 5:27 pm
    But somehow the execevalvar is being called. When i changed the logic of its
    working to use slot_getattr instead of cute_datum_array for the first run /
    call, everything just worked!

    This would indicate surely that the function does get called at least once
    before being called by executor for qual check. This is what got me confused
    - where does the function get called? Gdb trace says its first call comes
    through ExecutePlan but results say something else. Moreover, gdb still
    confuses me. Is there some gui to gdb? :(

    The only thing i am trying to make sure that ExecEvalVar gets the values
    from cute_datum_array only when called durin a scan, no way before it. May
    be there could be another way. I think i have to rethink about this.
    --
    Sent from my Android
    On 25 May 2011 20:34, "Tom Lane" wrote:
    Alvaro Herrera <alvherre@commandprompt.com> writes:
    Excerpts from Vaibhav Kaushal's message of mié may 25 05:52:32 -0400
    2011:
    If the above is confusing, I just want to ask: "Is expression evaluator,
    even in part responsible for {PLANNEDSTMT creation?"
    Yeah, as far as I understood Tom's talk, the expr evaluator is used to
    reduce some expressions to constants and such.
    The planner would never call it with an expression containing a Var,
    though.

    regards, tom lane
  • Robert Haas at May 25, 2011 at 5:32 pm

    On Wed, May 25, 2011 at 12:34 PM, Vaibhav Kaushal wrote:
    But somehow the execevalvar is being called. When i changed the logic of its
    working to use slot_getattr instead of cute_datum_array for the first run /
    call, everything just worked!
    This is what gdb is for... set a breakpoint on that function using "b
    ExexEvalVar", and when it hits the breakpoint, use "bt" to see where
    the call came from.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • Vaibhav Kaushal at May 25, 2011 at 6:15 pm
    I think the command 'where' does the same. And the command showed something
    which looked like was part of evaluation...it got me confused. Anyways,
    thanks robert. I will check that too. I did not know the 'bt' command.

    --
    Sent from my Android
    On 25 May 2011 23:02, "Robert Haas" wrote:
  • Vaibhav Kaushal at May 27, 2011 at 3:33 am
    OK, I ran a GDB trace into ExecScan and here is a part of it:

    #########################

    (gdb) finish
    Run till exit from #0 ExecScanFetch (node=0x1d5c3c0,
    accessMtd=0x55dd10 <SeqNext>, recheckMtd=0x55db70 <SeqRecheck>)
    at execScan.c:44
    194 if (TupIsNull(slot))
    (gdb) s
    205 econtext->ecxt_scantuple = slot;
    (gdb) s
    206 int num_atts = slot->tts_tupleDescriptor->natts;
    (gdb) s
    207 elog(INFO, "========[start] BEFORE ExecQual===========");
    (gdb) s
    206 int num_atts = slot->tts_tupleDescriptor->natts;
    (gdb) s
    207 elog(INFO, "========[start] BEFORE ExecQual===========");
    (gdb) s
    elog_start (filename=0x7c9db2 "execScan.c", lineno=207,
    funcname=0x7c9e69 "ExecScan") at elog.c:1089
    1089 {
    (gdb)

    ##########################

    Why do these lines:

    ########################

    206 int num_atts = slot->tts_tupleDescriptor->natts;
    (gdb) s
    207 elog(INFO, "========[start] BEFORE ExecQual===========");

    ########################

    repeat twice? I have written them only once! GDB documentation does not
    help! A few forums I am on, people accuse me of anything between bad
    programming to recursion. Any idea? I never face this with rest of the code
    (and in no other program). I am on Fedora 13 X86_64.

    Regards,
    Vaibhav

    On Wed, May 25, 2011 at 11:45 PM, Vaibhav Kaushal wrote:

    I think the command 'where' does the same. And the command showed something
    which looked like was part of evaluation...it got me confused. Anyways,
    thanks robert. I will check that too. I did not know the 'bt' command.

    --
    Sent from my Android
    On 25 May 2011 23:02, "Robert Haas" wrote:
  • Tom Lane at May 27, 2011 at 3:48 am

    Vaibhav Kaushal writes:
    Why do these lines:
    ...
    repeat twice?
    Hm, you're new to using gdb, no? That's pretty normal: gdb is just
    reflecting back the fact that the compiler rearranges individual
    instructions as it sees fit. You could eliminate most, though perhaps
    not all, of that noise if you built the program-under-test (ie postgres)
    at -O0.

    regards, tom lane
  • Vaibhav Kaushal at May 27, 2011 at 3:59 am
    Thanks Tom. Comparing to you people, I am definitely new to almost
    everything here. I did debug a few smaller programs and never seen anything
    as such. So asked. Moreover, those programs I compiled never used any
    optimization.

    While everything seems to be working, it looks like the slot values do not
    change and all rows in a sequential scan return the first value it finds on
    the disk, n number of times, where n = number of rows in the table! I am
    going to compile without optimization now. Hopefully that would change a few
    things in the debugging process.

    Seems beautiful, complicated, mysterious. And I thought I was beginning to
    understand computers. :)

    Whatever be the case, I will look more into it and ask again if I get into
    too much of trouble.

    Regards,
    Vaibhav
    On Fri, May 27, 2011 at 9:18 AM, Tom Lane wrote:

    Vaibhav Kaushal <vaibhavkaushal123@gmail.com> writes:
    Why do these lines:
    ...
    repeat twice?
    Hm, you're new to using gdb, no? That's pretty normal: gdb is just
    reflecting back the fact that the compiler rearranges individual
    instructions as it sees fit. You could eliminate most, though perhaps
    not all, of that noise if you built the program-under-test (ie postgres)
    at -O0.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 25, '11 at 9:57a
activeMay 27, '11 at 3:59a
posts11
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase