 So we will be discussing about the new feature which went into 5.7, which is the generated columns or the virtual columns that we know about. So there is a logic behind not calling this feature as virtual columns because it can be truly virtual or it can be a generated expression which you can store in your address also. So that's the reason we call it as generated columns. So the first question that comes to mind is why do we need generated columns? So the obvious answer says like everyone has it, so we also named something of that. And apart from that, we wanted to figure out like how are we going to store something which will help us for, let's say if you really have some complex expression, a complex condition in your queries and you are recurrently using it into your queries. So we can have it as a materialized storage for those complex conditions in your table itself. The other use case that we have is you can actually use it as a functional index that you create an index on a function. So you can use it as a functional index also. And the third and one of the most important reason of implementing this feature was that this basically complements the JSON data type that we had implemented in 5.7. And since we do not have a current indexing feature on the JSON data type, so this virtual column features will help you index your JSON data to some extent. So this is the basic syntax of virtual columns that you are going to mention while creating your table. So you mention the data type and then you have this. So you can have this or you can just omit this. And this is the expression that you need to give during your creatable statement which will help, which will actually generate the values based on the expressions. And the expression can have different column names, different functions, anything, anything. It can have any condition. And then you mention it, then you mention what type of generate columns you want. So you really want it to be purely virtual or you want to actually store the data. And then you can also define keys on these generated columns. So you can either define the keys during your creatable statement or you can later on add those keys with an alter table statement going forward. So basically the values that goes into a generated column is generated from this expression. So this is what you need to take care of when you are defining your generated columns. So I'll just go back and talk a little bit about the stored and the virtual part. So by default, if you don't mention anything, it is just virtual. Virtual in the sense like nothing is going to be stored. You just create the definition of the table and when you access the table, the values are generated on the fly. And when you mention it is stored, then what it does is it acts something like a material as cash for the complex expression. So yeah, that's all. So the virtual column values are calculated on the fly and the values are not at all stored. So whereas in case of the stored columns, the values are stored whenever a new record is inserted into a table. So whenever you insert a record into the other columns in the table, if this expression has those columns involved, then it will be generated and stored in the table. So in the later part of 5.7 releases, we had implemented the index support for both the generated columns, both for stored as well as the virtual values. So use cases, the first thing that comes into our mind is it can be used as a functional index. So let's assume you have a table where you have certain orders and price and stuff like that and you want to just sum it up to the quantity with the price, sum of the price. So basically this is how you define it. So sum price, decimal, generated, always a quantity which is here into the price. So add then you define it as virtual. And then going forward, you can either add the alter table column to add an index over there or you can basically just, if you don't want an index, you can just leave it as it is. So what happens is, so whenever you try to insert a data into the other columns, this expression is going to be generated and the data is going to be stored. If it is stored or whenever you access the table, then this going to be generated. So going forward, you can either do an alter table and add an index. It will be an online index creation, so you don't need to do anything. You have to just leave the index and the index can be queried based on your condition that if you have any kind of condition on this column. So the index can be used. So this is an interesting example. So very, very complex scenarios of what I'll do is this basically a creative statement. I'll just ask you to take a look at the date borrowed time, the date return time and the base point time. Sorry, the columns. So this is a schema for the library management system where you have a table, like a lending table and you lend, basically you lend your books to different users and they have this borrowed date as well as the date return and the base fine amount. So what we are trying to show here is you have a column which is a fine amount that is going to be generated with this expression. So just keep these three columns and this fourth one. So here it is. So the fine amount that we are going to... So basically I've implemented a small logic over here. So if you borrow a book and if you return it within 10 minutes, you don't need to be very fine. But if you return it within a certain period of time, that's a 10 to 20 days, then a fine amount is calculated based on the condition. And it goes that way. So if you return it within 20 to 30 days, there is certain amount and if it is more than 30 days, then you need to calculate the amount. So this is the kind of expression that you can have. You can have a very complex expression inside your creative statement or going forward. So if the date borrowed is... The difference between the date return and date borrow is greater than 10 and less than 20, then the base fine will be defined as this. Then you have the base fine which is there. And if it is between certain period, then you have your own logic to apply the fine. So when this feature was not implemented, this kind of... If your application had this kind of a logic, then you would have to implement the whole thing in the front end. Now, going forward with the feature of generated expression, you can have the whole logic inside your creative statement. So whenever you insert... So let's assume that someone borrows a book and returns after 20 days and then the person sitting on the terminal just enters the date return and the fine amount that he has to pay will be automatically calculated and that column will have that fine amount. So that's how... It's very simple to use. All you need to take care is just take care of the expression and whether it's serving your purpose or not. So based on that, you can go ahead and... One question. Yeah. If I make it stored... So next time if I go to the table, that's when the stored data will be again calculated. Exactly. No, no, no. If you insert it, it is calculated. Because if you have... If you insert it, it is already stored in the stored application. And if I say virtual, every time I search a query... Every time you do a select... I'll come to that. So what is it with this now? You can add a condition over here. The date return is... See, if you go to the previous statement, this is an ordinal column, right? It's a column name. The date return is a column name. Yeah. So what you are doing is... Let's assume that this is a table and you are entering a data into that. So if the date return is null, you can have a condition... I've not implemented that, but you can have a condition over here saying to do nothing or just insert null. If I forget to do that? That will be a default column. So if you see, you can have it as a default column. So whenever a person returns a book, you can probably have an insert statement or an update statement saying that update the date return does this. So once you update the date return, this will again get calculated. So sister, why this thing? The data is not persistent. Every time you do a query, you regenerate them. Yes. So it depends on how you define it. If you define it as a stored column, it will be a persistent data. If you define it as a virtual column, the moment you do a select, it will calculate on the fly. This is how it is done. So either you can have it as a stored data or you can have it as a virtual, purely virtual data, which will get calculated whenever you access the column or access the table that way. Why do you call it always? No, that's an optional thing. You can omit this part. You can have just data type as something. It's defined as generated. So something of a syntactical match. So very simple example on how to insert data into a generated column. So you cannot directly insert data into the generated column. So it has to be... So there are two ways of doing it. If your table has a column which is generated, either you do an insert into table and don't... Whatever are the base columns, just mention that and insert the value. Or do an insert into table and mention it as default. So this is the thing. So if you mention default, during the insertion, it will insert whatever values are calculated over here into that. This is how you would... And it is not allowed to directly insert into table and insert that operation happens when there is a change to the base columns. So what happens is if you do... If you have already inserted into... If you have values in this, if you are updating this, then this will automatically get completed at the publishing time. So that's how it works. Okay, now coming to the indexes on generated columns. So these are certain features which are already implemented. So for a store generated columns, you can define a primary and a secondary key. You can... All these indexes are supported. You can define a full text search index or a GIS index. And since this is store, whatever data you insert requires a table rebuild and this is not allowed. And for virtual indexes, you can only define secondary keys. It supports B3s. You don't require a table rebuild. And it's an instant auto. So you can add your indexes using an instant auto command. Some fine points on indexes of virtual columns. So if you are creating an index on a virtual column, the index data is stored. It is materialized and stored into secondary index columns. Because obviously if there's a huge data, you cannot create the index all the time if it's created virtually. So you need to store certain... So this index data is going to be stored. And this is how you can either do a create index on table or you can do an alter index and add it on the table to create the virtual columns. Okay, so this is the most important use case for virtual columns is using it with JSON data. The JSON presentation is just after my presentation and my colleague is going to do a talk on JSON and whatever JSON implementation went into 5.7. But this is what we do. So what it does here is, let's assume that you have a table and you have inserted certain JSON data. And then what you... So you are having a question, right? That you are having a question, right? On JSON, how to index JSON data? So this is how you do it. So whenever you use a JSON data, you would basically be using... You would be basically looking for certain keys, right? The key values. So what you do here is, you define a virtual column in this way. So let's say id int and then you use the JSON function which is JSON extract. Extract the values and create it as a virtual column. And then you do an index on that. So if you do an explain, it looks like this. What it will do is it will use the keys and it will use the optimizer, the range access and it will filter the data and it will show you the data in this way. Now if you have a query like this, select data from t1 where id between 3 and 5, where id is basically the virtual column over here. Then you basically are using the virtual index on the virtual column. So this is how we advise all the users of JSON data to index their fields and use it in their application. So there are a couple of limitations right now with respect to the generated column stuff. They may or may be lifted. I'm not sure about it. I cannot guarantee over here. So one of the limitations is you have to use deterministic function in the generated column expression. You cannot use a function something like a current time stamp or something like that because everything won't change. Then there is a limitation on the length of the expression. So they cannot be longer than 64 key. And so in a complex kind of a scenario you can define a generated column based on previously defined generated column. So you have a level of testing while defining generated column. So based on certain column, then take an expression. But the only condition is those columns has to be defined previously. I mean let's say you have column c1, c2. The limit means the level you can go down. There's no limit to that. But the only condition is, the only limitation is those columns has to be defined prior to that. Of course. Primary keys are not supported for virtual columns. Spatial and Fultix index are virtual columns and are not supported. And it cannot be used as a warranty right now. But probably this limitation might... We have plans to support ODF when coming versions, but not right now. Okay. That was a short presentation. Any questions you have? It means it will be good if you are adding a column, index on a virtual column. Just like as fast as you are adding a virtual column. It means adding on a virtual column will take same amount of time when you are adding index on a non-virtual column. So it will be good if this performance would be somewhat near future. It is same because the moment you add an index it is stored in the artist. So that's... If you create everything on the fly with the amount of data, it will... There will be a lot of performance on it in that time zone. But you can basically have a lot of logic into your expression and you can implement it that way. That's one of the biggest benefits of this. Thanks a lot. Any other questions you have? No questions? So, okay. Round of applause, David. Thanks.