No triggers defined on the tables....or on the database for that matter.
Seems to just be choosing to invoked the GENROW function on very similar
SQL statements against 2 different tables.


                                                                                       
                                                
                      "Scott Saunders"                                                 
                                                
                      <[EMAIL PROTECTED]        To:       [EMAIL PROTECTED], [EMAIL 
PROTECTED]                                    
                      iebel.com>               cc:                                     
                                                
                                               Subject:  RE: [DB2EUG] SYSIBM.GENROW 
showing up in explains?                            
                      09/11/2003 07:50                                                 
                                                
                      AM                                                               
                                                
                                                                                       
                                                
                                                                                       
                                                




Tim;
You might want to check for triggers on the table being
inserted/updated/deleted.  I have seen GENROW in explains under those
conditions.

Scott Saunders
Siebel Expert Services


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 2:57 PM
To: [EMAIL PROTECTED]
Subject: RE: [DB2EUG] SYSIBM.GENROW showing up in explains?






Is there a way to disable its use or is it part of the db2 optimizer and
gets used when the optimizer decides it needs to be used.  We have a
couple of very similar update statements that we are doing explains on
and the one that is using the GENROW function seems to "cost" more when
it is used as opposed to the explain that doesn't use the GENROW
function.


----- Forwarded by Tim Traxson/Corporate/JBHunt on 09/09/2003 01:53 PM
-----


                      "Sinha, Abhijit"

                      <[EMAIL PROTECTED]        To:       "'Reys, Ellen'"
<[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]'"
                      .com>
<[EMAIL PROTECTED]>, [EMAIL PROTECTED]

                                               cc:

                      09/09/2003 08:41         Subject:  RE: [DB2EUG]
SYSIBM.GENROW showing up in explains?
                      AM









>From IBM doc:
=============
Operator name: GENROW

Represents: A built-in function that generates a table of rows, using no
input from tables, indexes, or operators.

GENROW may be used by the optimizer to generate rows of data (for
example, for an INSERT statement or for some IN-lists that are
transformed into joins).

To view the estimated statistics for the tables generated by the GENROW
function, double-click on its node.

Abhijit

-----Original Message-----
From: Reys, Ellen [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2003 7:18 PM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: [DB2EUG] SYSIBM.GENROW showing up in explains?


I have seen GENROW many times in the Optimized SQL statement in the
exfmt output. In my case, this was related to the eliminating
unqualified branches in the UNION ALL VIEW when joined to a table. In
that case, the unqualified branch is transformed to a nested loop join
(NLJOIN) with the outer input (left hand side) is a GENROW and the inner
input (right hand side) is the table name (if doing table scan) or one
of the index of that table (if doing index scan) of the unqualified
branch.

The way the plan works is it starts to evaluate the predicate in the
GENROW, which is in the form of:

            (query predicate) AND (view definition predicate)

For example,

             month_id = 72001 AND month_id in (102000,112000,122000)

In this case, the predicate will return false and the GENROW will
produce no row. The NLJOIN will not access its inner input, which is the
access to the table (or index).

Sorry, if I cannot explain properly.

Ellen Klebaner-Reys
Data Management Services
Inovant - a Visa Solutions Company
[EMAIL PROTECTED]/650-432-1746  m/s: 3125-1D



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2003 2:35 PM
To: [EMAIL PROTECTED]
Subject: [DB2EUG] SYSIBM.GENROW showing up in explains?






Somehow SYSIBM.GENROW keeps popping up in explain diagrams. Can't find
this object however. Does anyone know what's the purpose of this one?

Thanks,
Tim

-
:::  When replying to the list, please use 'Reply-All' and make sure
:::  a copy goes to the list ([EMAIL PROTECTED]).
***  To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
***  For more information, check http://www.db2eug.uni.cc
-
:::  When replying to the list, please use 'Reply-All' and make sure
:::  a copy goes to the list ([EMAIL PROTECTED]).
***  To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
***  For more information, check http://www.db2eug.uni.cc


-
:::  When replying to the list, please use 'Reply-All' and make sure
:::  a copy goes to the list ([EMAIL PROTECTED]).
***  To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
***  For more information, check http://www.db2eug.uni.cc





-
:::  When replying to the list, please use 'Reply-All' and make sure
:::  a copy goes to the list ([EMAIL PROTECTED]).
***  To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
***  For more information, check http://www.db2eug.uni.cc

Reply via email to