Hi Paul
Paul DuBois wrote:
>
> On May 19, 2009, at 11:07 AM, Marc Alff wrote:
>
>>
>> Hi Guilhem
>>
>> Guilhem Bichot wrote:
>>> Hello Marc,
>>>
>>> I see that for files, object_instance_begin is always 0 in my tests:
>>>
>>> mysql> select * from EVENTS_WAITS_SUMMARY_BY_INSTANCE where
>>> object_instance_begin=0 order by 1 ;
>>>
> +---------------------------------------------+-----------------------+------------+----------------+----------------+----------------+----------------+
>>>
>>>
>>> | EVENT_NAME | OBJECT_INSTANCE_BEGIN |
>>> COUNT_STAR | SUM_TIMER_WAIT | MIN_TIMER_WAIT | AVG_TIMER_WAIT |
>>> MAX_TIMER_WAIT |
>>>
> +---------------------------------------------+-----------------------+------------+----------------+----------------+----------------+----------------+
>>>
>>>
>>> | wait/io/file/maria/control | 0 |
>>> 6 | 113417304 | 1987986 | 18902884 |
>>> 62948886 |
>>> | wait/io/file/maria/log_descriptor_directory | 0 |
>>> 2 | 85008924 | 5579574 | 42504462 |
>>> 79429350 |
>>> | wait/io/file/maria/recovery_trace | 0 |
>>> 7 | 182696514 | 780780 | 26099502 |
>>> 60282222 |
>>> | wait/io/file/myisam/dfile | 0 |
>>> 1 | 12882870 | 12882870 | 12882870 |
>>> 12882870 |
>>> | wait/io/file/myisam/dfile | 0 |
>>> 1 | 12924912 | 12924912 | 12924912 |
>>> 12924912 |
>>> | wait/io/file/myisam/dfile | 0 |
>>> 4 | 24180156 | 1285284 | 6045039 |
>>> 13159146 |
>>> | wait/io/file/myisam/dfile | 0 |
>>> 3 | 17951934 | 1327326 | 5983978 |
>>> 13975962 |
>>>
>>> As this is a "by_instance" table (one line per MyISAM data file, the
>>> dfile lines above), I expected a discriminating information to be
>>> present, so that I can know, among the 3 dfile above, which one belongs
>>> to what; for this, I expected file names to show up.
>>> I see that for mutex instances, the column is not 0.
>>
>> object_instance_begin is only an address, it can not be a file name.
>>
>> For files, there is no "identity" pointer that can be used, since there
>> is no file object the code can use (FILE* is a file handle, not
>> representative of the underlying file itself).
>>
>> So, I used the address of the PFS_FILE* structure itself for:
>> - EVENTS_WAITS_CURRENT.OBJECT_INSTANCE_BEGIN
>> - EVENTS_WAITS_HISTORY.OBJECT_INSTANCE_BEGIN
>> - EVENTS_WAITS_HISTORY_LONG.OBJECT_INSTANCE_BEGIN
>> - EVENTS_WAITS_SUMMARY_BY_INSTANCE.OBJECT_INSTANCE_BEGIN
>>
>> so that there is always a discriminant in OBJECT_INSTANCE_BEGIN,
>> globally unique
>
> Does the PFS_FILE* structure have any meaning for users, or is the only
> relevant thing about it that different values indicate different files?
>
Different values indicate different files, the value itself has no meaning.
>> Now, this raise the question about adding an OBJECT_INSTANCE_BEGIN
>> column in FILE_INSTANCES, so that we have both the file name and
>> address, to join data ...
>
> My next question was going to be, is there any way to associate a given
> OBJECT_INSTANCE_BEGIN value with a file name? I take it the answer is "no."
Correct
>
>> The same question will arise for tables, where a table can be named:
>> - either by schema + name
>> - or by object_instance_begin (the address of the table share),
>>
>> when we get to something like TABLE_INSTANCES, and summary by tables.
>>
>> Peter, any opinion ?
>>
>>
>>
>>
>> --
>> MySQL Code Commits Mailing List
>> For list archives: http://lists.mysql.com/commits
>> To unsubscribe: http://lists.mysql.com/commits?unsub=1
>>
>
