db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: Should we have dynamic like optimization with TERRITORY_BASED collation
Date Mon, 23 Jul 2007 17:45:31 GMT
Kathey, this is another behavior we picked up from national character
types.  LikeEscapeOperatorNode has following comment
        /* If we are comparing a char with a national char then
         * we generate a cast above the receiver to force preprocess to
         * not attempt any of the > <= optimizations since there is no
         * way to determine the 'next' character for the <= operand.

Mamta


On 7/23/07, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
>
> The test below fails in DynamicLikeOptimizationTest.    I wonder is this
> optimization expected for
> TERRITORY_BASED collation or is ok that it is not done.
>
> Kathey
>
>
>   /**
>     * Test that dynamic like optimization is performed. That is, the LIKE
>     * predicate is rewritten to &gt;=, &lt; and LIKE.
>     */
>    public void testDynamicLikeOptimization() throws SQLException {
>        Statement s = createStatement();
>        s.execute("CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1)");
>        PreparedStatement ps =
>            prepareStatement("select id from test where vc10 like ?");
>        ps.setString(1, "%");
>        JDBC.assertDrainResults(ps.executeQuery());
>        RuntimeStatisticsParser p =
> SQLUtilities.getRuntimeStatisticsParser(s);
>        *assertTrue(p.hasGreaterThanOrEqualQualifier());*   <-- FAILS HERE
>        assertTrue(p.hasLessThanQualifier());
>        s.close();
>        ps.close();
>    }
>
>
>
>

Mime
View raw message