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.
>
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
