ourdelta-developers team mailing list archive

["MARK CALLAGHAN" <mdcallag@xxxxxxxxx>]

On Sun, Oct 19, 2008 at 5:50 AM, Arjen Lentz <arjen@xxxxxxxxxxxxxxxx> wrote:
> Hi Mark
>
> On 16/10/2008, at 1:34 AM, MARK CALLAGHAN wrote:
>>
>> On Tue, Oct 14, 2008 at 1:20 PM, Arjen Lentz <arjen@xxxxxxxxxxxxxxxx>
>> wrote:
>>>
>>> On 15/10/2008, at 12:15 AM, MARK CALLAGHAN wrote:
>>>>
>>>> On Mon, Oct 13, 2008 at 9:25 PM, Arjen Lentz <arjen@xxxxxxxxxxxxxxxx>
>>>> wrote:
>>>>>
>>>>> You'll be happy to know that these enhancements are like a prime
>>>>> selling
>>>>> point, knowing which indexes are actually getting used is soooo useful.
>>>>>
>>>>> Does the INDEX_STATISTICS keyword (and the others) actually need to be
>>>>> reserved words?
>>>>> They are now, as the equivalent information_schema tables need to be
>>>>> backtick quoted in a query to not chuck a syntax error.
>>>>
>>>> We have been lax about this for many of the changes we made to the
>>>> parser. It doesn't need to be a keyword.
>>>
>>> Okidoki, then we're on the same page. Thanks.
>
> Found & fixed, pushed in
> https://code.launchpad.net/~arjen-lentz/ourdelta/ourdelta-userstatsv2
>
> Apart from the useful exercise for me (I'm sooo rusty), I decided it has
> real-world relevance.
> Chances are some people will have tables or columns named user_statistics or
> client_statistics, and thus their application would break the moment they
> start using a MySQL built with this patch.
>
> And then I also found the FLUSH SLOW QUERY LOGS addition hiding inside this
> patch.
> Also fixed up the keyword there, people are bound to have some identifier
> named `logs`.
> I extracted it to be separate, and documented both (some based on your wiki
> page)

I think we eventually switched back to FLUSH SLOW QUERY LOG to avoid
that problem.
>
>
> Question, Mark: some of the userstats appears to be MyISAM/InnoDB specific
> (there's code in ha_myisam.cc and ha_innodb.cc), is there a specific reason
> for this (like required info not available outside), or could it possibly be
> made generic for all engines?
> I'll want to document this fact, as for instance PBXT might want to add in
> foo to be included also.
> Thanks
>

I think that you can do all of this in handler.{cc,h} but it might
require a lot of changes. I prefer that all of the counting be done in
handler.{cc,h} but that requires that the existing methods to
read/insert/update/delete a row be helper methods and not get called
directly by non-handler code. Non-handler code should call the new
methods in handler.{cc,h} that increments the count and calls the
helper. But to make this work, either non-handler code has to be
changed to call methods with new names or all engines have to be
changed. It is probably easier to change non-handler code.

We haven't been willing to make those changes yet.

>
> I left the SHOW command stuff; since I was able to get rid of the reserved
> words, it's no longer an issue to try and get rid of them ;-)
>
>
> Cheers,
> Arjen.
> --
> Arjen Lentz, Director @ Open Query (http://openquery.com.au/)
> Training and Expertise for MySQL in Australia and New Zealand
>
> OurDelta: free enhanced builds for MySQL @ http://ourdelta.org/
>
>
>
>



-- 
Mark Callaghan
mdcallag@xxxxxxxxx