maria-developers team mailing list archive

[Alexander Barkov <bar@xxxxxxxxxxx>]

Forgot to mention.
We'll discussed this on slack already,
writing for records anyway.

There is no a need for Item_func_{day|year}_{start|end}.

You can create Item_{date|datetime}_literal instead.
Optimization now works only if the second argument in
the comparison is a basic constant. So it's OK to
call get_date() for it during fix_fields() time.



On 11/30/2017 04:19 PM, Alexander Barkov wrote:
> Hello Sergey,
> 
> I generally like your patch for MDEV-8320:
> 
> http://lists.askmonty.org/pipermail/commits/2017-November/011680.html
> 
> 
> However, there is one problem with it.
> 
> We're changing the code to have data type plugins.
> 
> Every data type plugin will provide its own list of SQL functions.
> Those data type specific functions should be able to use
> the same optimization approach without having to change
> the server code.
> 
> Therefore, everything related to YEAR(field) transformation
> should reside inside Item_func_year,
> everything related to DATE(field) transformation should reside
> inside Item_date_typecast.
> 
> I reorganized the code to implement this idea.
> 
> 
> 
> Note, also I changed the logic behind DATE(indexed_date_field)
> transformation slightly. The DATE() just gets removed.
> 
>    DATE(indexed_date_field) = const
> 
> is changed to:
> 
>    indexed_date_field = const
> 
> instead of:
> 
>    indexed_date_field BETWEEN ... AND ...
> 
> Please have a look:
> sargable_date_cond.result is slightly different in my version.
> 
> 
> Greetings.
>