 So, discussion today is mostly about the new feature which is introduced and the point is this change in the server is mostly internal infrastructure change, so it is not something that you directly feature for end user, but it is the internal component change and enables us to improve minuscule and enhance it in future. So, we will just go through what are the changes which we have done, so this is the same further statement that we this is a current function purpose, so the talk here will be focusing on what is data dictionary, how does it look prior to ADOTO version and what advantages do we get in ADOTO announcements, so what is data dictionary as we all know and we create a table, in a create table definition we provide what is the information you are planning to store, so this first row indicates metadata and these rows are basically data which is stored, so the talk is about how we manage the metadata and the collection of all metadata which a database source is called as data dictionary, now what is the role of data dictionary in a typical database server, so when you fire a query and say select star from employee and the executor basically needs to know whether such a table exists, so that is when the subsystem is contacted, so whether a field exists, whether the store procedure exists, so this is a central repository for all the metadata, so it is a generic picture of how it looks for all the databases, now let us look at how it is managed before ADOTO, so if we look at 5.7 this is before ADOTO, the table information is spread across different flat files, so the columns are stored in FRN, the triggers are stored in .trn and .trg, the schema property like gassets are stored in a flat file called a gopt, so partition information is stored in .par and then the stored procedure metadata is stored in table based myism engine where it is non transactional and there is also a duplicate copy of the table which is stored in inner database, so if you can see the metadata which is required by mySQL is spread over different formats it is not there is no universal way that this is how you store metadata in data, so what is the problem with this, this is how mySQL has been evolved over years and this is what we have right now and what are the problems out of it, so if you see the server has to manage this with implementation specific to files, so if server needs to store tables there is a different module which handles, if server needs to store procedures, users and events there is a different module the server infrastructure has to manage, so there is no common infrastructure to manage the dictionary information in the server. What are the problems because of it and these problems have been observed since like 10 years or more than 10 years and there are numerous bugs and it is almost some of the issues we could not even fix because the dictionary information is all spread, so one of major concerns is information schema queries where the way it works today is when you file information schema query we internally create a temporary table, the server gathers information metadata from a flat file or mySQL table or even in your table fills in and until that user will see the data, so you can just imagine how much time it will take for a single information schema query to work and if your database instance is big the time taken is huge, so this is one of the problem, the second problem is inconsistency due to non transactional storage, so you are creating a stored procedure and it is not transactional and we have fixed many issues around that, there are issues around inconsistency between InnoDB keeping a metadata store and server's metadata like FRM, so you have FRM content which has a column and InnoDB does not have it, so user could end up in such a situation and you cannot control that and this is a so stopper as if server needs this infrastructure they cannot live with varieties of formats as it works now, so this has to change and replication is challenging, so the way details are logged there are issues around that and it is all custom handling that you for each case, so it is not a good architecture and it is difficult to extend, suppose if server needs to show new set of metadata and we have different poly formats the architecture goes more worse, so what is done in 8.0 is we have consolidated all, I mean the metadata spread is not spread anymore and it is stored in InnoDB tables, the server uses InnoDB table to store the metadata of tables, stored procedure, events, ACLs and all that, so it is centralized, so if you look at advantage we all metadata is stored in relational tables now, then it is a single store, so the advantage of it is now it opens a door for more enhancements like a plugin can store metadata now in the dictionary and it is very easy to implement new details which can store metadata, it brings in a new formal interface and yes now information schema gets faster because the old way of working where we need a temporary table is gone, it can just be a view over dictionary tables, this is just the way it works, so if you run information schema query now it just goes through optimizer and it is a view which is just based on the dictionary tables, so this brings us I mean we will just show how what we gain out of it, so as I described this infrastructure is mostly change in the core of my SQL server, so what you see as a end user right now is we get two major things, information schema performance is improved and now DDL operations are more reliable, so it enables door to make DDLs atomic and then we have serialized data information, where you can move a table from all instance to other using serialized dictionary information and we also introduce a new command there for import, so if you have data file, SDA information and if you run import command you just transfer a table from all instance of my SQL to the other and this is another bigger advantage, this enables us to automate data dictionary upgrades, now we have we can number the version, suppose this instance of my SQL has version and if the next release has changed some of the columns internal data structure data dictionary type, it gets automatically upgraded if you start the server with the old database, so that infrastructure and this is also a big thing that there are numerous issues during upgrade, so it was not easy to find, so this brings in the infrastructure for us to simplify things, so this is a comparison of 5.7 how it works and 5.8 how information schema would work, so if you focus on 5.7 if I fire a query I create a temporary table and the temporary table will be filled with information from file system, myajam and you know db table and then rows would be read from temporary table, so this was the architecture in 5.7 and in 8 we do not have anything of this this if I fire an is query it just works as if it is a user query, all the optimization which you get on a user query would be applied for is query, majorly the indexing part the indexes which are installed on the dictionary tables are helping execution of is query whereas here we do not have indexes it just gets versa and versa if your instance is big, so when you benchmark with 5000 tables and if you use information schema query to least ignore db table columns, so what I am doing just is I have 5000 tables and I just want to know all the column name in the instance and the gain we can see here is multiple, so minimum 30 times faster and then in certain scenarios if you increase number of tables in your instance, we have even observed more than 100 times of improvement and for some of the customer this is really a pain point there are customers who was server almost hung on their instance the query just hangs the server freezes, so you can just imagine there are customers with 100 k tables and more and sometimes in several cases they are scared to use schema, information schema that is the feedback we have got. So what the other benefits of server having common data dictionary tables are it provides an automatic ideal where in the replication operations become simple where it is number of issues we have faced due to crash during the ideal being executed because it was not atomic and then as we discussed now data dictionary is version which enables automatic upgrade management and then moving around the file, moving around the table from one instance to other, this was the way we used to do we if you want to move another db table you have to create table then say auto discard and then auto import and now the data auto you just have one command called import and using the serialized information which is already stored the data dictionary will be updated. So yeah, so the reason of the major advantage is we and out of which as I told when I started the talk this introduction of data dictionary is majorly infrastructure change which enables us to advance minus scale further it simplifies things reduces the problem. Yeah, that is all I had. What is you mean by atomic pdl? Yeah, so we have alter suppose if you have alter yeah, so right now if it crashes when alter is in progress in between so alter has various phases now. For example, we create a new table switcher and that is stored in the disk and form a paper and then we move on to a phase where we copy data from the original table into this and if there is a crash we have a temporary table left over. So, there are issues where there is a crash somewhere goes down and then you will see there are several temporary dot afference the hash is clear dot afference present on your disk. So, with this you will you will end up it is like you call it is like a transaction start and stop if transaction is not committed nothing is preserved it is rolled back to the previous. Do you have any questions? No. You have a place where I can. No. E. E. E. E. E. E. E. E. E. E. E. E. E. E. E. E.