db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Should we have dynamic like optimization with TERRITORY_BASED collation
Date Mon, 23 Jul 2007 17:48:11 GMT
Mamta Satoor wrote:
> 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
>
Sounds intentional. Thanks Mamta

>  
> On 7/23/07, *Kathey Marsden* <kmarsdenderby@sbcglobal.net 
> <mailto: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