[
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.
