Hello Peter,
Peter Gulutzan a écrit, Le 27.06.2009 00:37:
> Hi Guilhem,
>
> Guilhem Bichot wrote:
>> Hello,
>>
>> Peter Gulutzan a écrit, Le 22.06.2009 22:15:
>>> Hi Marc,
>>>
>>> Marc Alff wrote:
>>>> Hi Guilhem
>>>>
>>>> Guilhem Bichot wrote:
>>>>
>>>>> Salut Marc,
>>>>>
>>>>> 1) EVENTS_WAITS_CURRENT.SPINS is always NULL; what is the plan for
>>>>> this
>>>>> column?
>> So, the column is NULL now, may be filled later.
>> Right now, if I understood correctly, the Performance Schema Interface
>> does not allow a developer to make his synchronization object report
>> to Performance Schema "I spun X times", so that X possibly ends up in
>> the SPINS column.
>> Why do we expose the column to the user already now, then? Shouldn't
>> it be added only later when we offer developers the API to fill it?
>> Won't we get questions from users like 'why is this column always NULL'?
>> What is the benefit of featuring it now?
>>
>
> Sometimes we don't "expose" a column if we have nothing
> to put in it, for instance that happened where the
> standard had INFORMATION_SCHEMA columns with values that
> didn't apply for our situation. I saw this as somewhat
> different, though, since (as you can see from the WL#2360
> quote above):
>
> * We do expect that the column will get exposure after
> we're instrumenting storage engines that have spinning.
> And we do expect that the column will be used. So this
> isn't so much a "not applicable" as a "not yet applicable"
> situation.
>
> * I saw the position of SPINS as being most appropriate
> just after the TIMER columns, since it's a consumption
> measure, if we really use it for spins. But if in a
> later version we add a column in the middle of a table
> rather than at the end, we might break an application
> that depends on column order. (It has happened.)
Thanks for the explanation Peter. Let's keep the column then. Case closed.
--
Mr. Guilhem Bichot <guilhem@stripped>
Sun Microsystems / MySQL, Lead Software Engineer
Bordeaux, France
www.sun.com / www.mysql.com
