db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2499) Update Tuning Guide documentation to reflect the new static IN list transformation that occurs as a result of DERBY-47.
Date Mon, 23 Apr 2007 16:51:15 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490986
] 

A B commented on DERBY-2499:
----------------------------

Laura,

This is looking great.  Only a few minor suggestions, most of which are necessary because
of my own poor wording the first time around:

1) Might be more clear to remove the "WHERE" keyword from the example IN predicates at the
start of the document.  I know I included "where" in my first writeup, but since that keyword
is not actually part of the predicate it would probably be better to remove it.  Also, is
it possible to indent the examples?

  Something like:

     The following are examples of simple IN predicates:

       orig_airport IN ('ABQ', 'AKL', 'DSM')

       orig_airport IN (?, ?, ?)

       orig_airport IN ('ABQ', ?, ?, 'YYZ') 

2) Reword:

     Derby transforms these IN list predicates into a single equality predicate ...

   to be:

     Derby transforms each IN list predicate into an equality predicate ...

  The original wording (as I wrote it) makes it sound like one probe predicate is created
for all simple IN predicates, which is not true.  Rather, a probe predicate is created for
*each* simple IN predicate in a query; i.e. Derby will generate multiple probe predicates
if a query has multiple simple IN predicates.

  I think you captured this nicely later in the document (see #3 below).

3) Remove the "WHERE" keyword from the following example, for reasons mentioned in #1.

    Each of the above examples of simple IN predicates is transformed into the
    following probe predicate:

    WHERE orig_airport = ? 

  And if it's possible to indent that line, that'd be great...

4) Remove the "WHERE" keyword from the following sentence:

    The probe predicate WHERE orig_airport = ? might appear like an equality
    comparison to a single value specified by the user, ...

5) Missing a period before "Then for each...", and a space before the comma, in the following:

    ... which Derby plugs the different values from the IN list Then for each
    value,Derby reads the matching rows from the index.

6) Is it possible to indent the JDBC and SQL examples?  Something about having the examples
left-aligned with the text looks odd to me.  But I admit, that could just be me :)

7) Looks like there is an extra "UNION ALL" piece in the SQL example.  I.e. I think you can
remove the following:

    select flights.orig_airport, cities.city_name    
      from flights, cities      
        where flights.orig_airport = ''        
          and flights.orig_airport = cities.airport 

    UNION ALL

8) The link to "NOT IN predicate transformations" sort of appears out of nowhere.  The same
is true on the current page (before any of your changes).  Can some kind of "see also" or
similar label be added here?

----

Other than these minor blips, the new page is looking good.  Thank you for taking the time
to formalize my initial proposal...

> Update Tuning Guide documentation to reflect the new static IN list transformation that
occurs as a result of DERBY-47.
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2499
>                 URL: https://issues.apache.org/jira/browse/DERBY-2499
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Documentation
>    Affects Versions: 10.3.0.0
>            Reporter: A B
>         Assigned To: Laura Stewart
>            Priority: Minor
>         Attachments: derby2499_1.diff, rtuntransform582.html
>
>
> DERBY-47 changed the static rewrite logic for IN lists.  Whereas we used to create a
BETWEEN predicate for IN-lists that contain all constants and then use that predicate to limit
the scan, we now create a "probe predicate" for IN-lists that contain all constants *and/or*
parameter nodes and then use that new predicate to perform execution-time probing.
> The documentation in the Tuning Guide needs to be updated to reflect this change in behavior.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message