WEBVTT 00:00.000 --> 00:17.000 Okay. Let's start. So my name is Levant. I'm with MySQL Optimizer team and our job is 00:17.000 --> 00:24.600 as you know to create performance issues and get complaints from you and maybe fix them. 00:24.600 --> 00:29.600 And what are tools we use a lot is explain. I guess is I want to hear don't use 00:29.600 --> 00:39.500 explain regularly. No, maybe a few. So since we're using so much we're also working 00:39.500 --> 00:47.600 on expanding the features and all that. So I wanted to talk about the current explain 00:47.600 --> 00:55.500 features. We added a few in the latest like since eight or what is. Then there are some 00:55.500 --> 01:00.500 restrictions on what you can do, how you can combine them and stuff. And that will 01:00.500 --> 01:06.160 become clear when you look at how explain actually works. And then we'll look into the 01:06.160 --> 01:17.360 crispable and see if we can predict something about the future of of explain. So this is what 01:17.360 --> 01:30.160 explain looks like. We have explain a lot of options and a statement on the end. And this 01:30.160 --> 01:35.320 doesn't work. Yeah, very good. The statement can be select insert update lead to replace 01:35.320 --> 01:42.440 or table. If you don't know table, it's like a sextor. And if you do explain statements, 01:42.440 --> 01:51.240 it will parse and prepare an optimized query, but not execute it. I think Ruben is not 01:51.240 --> 01:57.440 in room. He had an example of things actually being evaluated when doing explain. He did 01:57.440 --> 02:03.440 that at pre-fossil. So maybe go back and watch that video if you weren't there. So yeah, 02:03.440 --> 02:07.760 in some cases things may be evaluated, but obviously they're not executed. I'll get back 02:07.800 --> 02:16.200 to that when they explain how explain actually works. And you can explain what statement 02:16.200 --> 02:22.200 that gives you just the query plan. Explain analyze. So it will actually execute this 02:22.200 --> 02:27.560 thing and give you the query plan. And information about the execution, like how many 02:27.560 --> 02:32.760 roles and how long time everything took. And like to me, it was up early to talk about profiling 02:32.800 --> 02:40.440 CPU and memory. This is like an SQL level profiling of your query. We have different 02:40.440 --> 02:46.440 formats. We have traditional, we have JSON and we have tree. I guess you know this already, 02:46.440 --> 02:55.280 but traditional is this tabular format with one role per table and JSON is JSON. And then 02:55.360 --> 03:04.840 the tree formats is this where you have like a nice ASCII art tree has one string. And yeah, 03:04.840 --> 03:17.120 this is one line, one node of the tree per operation, the query. So this is one role per table, 03:17.120 --> 03:23.920 this is one node and three for each operation. So there's a different thing in how to express 03:23.920 --> 03:35.920 things. So if you get tired of saying format equals tree, all the time like I do, in 03:35.920 --> 03:42.400 eight or third or two, we introduce a system variable called explain formats. It can be default 03:42.400 --> 03:48.000 traditional JSON or tree, default just means traditional. At these other moment, it may 03:48.000 --> 03:53.520 change in the future, but if you said explicitly, you can do your explains without having 03:53.600 --> 04:03.920 to say form equals tree as I do. We also have one more variable called explain JSON format 04:03.920 --> 04:13.760 version. I think the Fred talked about a love of long system variable names. You can 04:13.760 --> 04:20.800 set in one or two, one is defaults. This was new in eight three oh, so it's quite recent. This 04:20.880 --> 04:28.480 applies if you're using the JSON format of course. So we actually JSON is not one format, 04:28.480 --> 04:36.720 we have two JSON formats. version one is what we had since I think five seven. Basically, 04:36.720 --> 04:46.800 it's a JSON objects with one sub-object per table and lots of options about it, but yeah, 04:47.440 --> 04:52.800 an option, an object for table and a table name and then lots of attributes on a table. 04:54.160 --> 05:06.240 version two is like this. This is from nine to zero. There is an object for, it says 05:07.360 --> 05:14.640 queer plan, that's the attribute, and then we have one object per operation in the queer plan. 05:14.640 --> 05:21.280 So the whole tree that we saw in the tree format is represented as one JSON object for each 05:21.280 --> 05:28.320 node in that preview. Actually, when we implement this, the format equals tree is a projection 05:28.320 --> 05:35.760 of some of the attributes in this new format. Again, this is one object per operation. 05:36.720 --> 05:44.400 And we're a bit late in adding this. We added the new JSON format of a three, but 05:45.360 --> 05:50.720 only nine two did we add the actual version number inside the object. But now you can actually 05:50.720 --> 05:55.760 look at this object and see that this is version two. It says two point all. It's a 05:55.840 --> 06:02.960 semantic version. So hopefully we never change two, but as we add stuff, we will go to two one, 06:02.960 --> 06:13.360 two, two, two, three, and so on. That was formats. Let's look at Analyze. That wasn't even 06:13.360 --> 06:21.760 a to 18. I hope you all have used that. Analyze is not compatible with the traditional formats 06:21.840 --> 06:28.000 or with JSON version one. You have to use three and you have to use JSON version two. 06:30.800 --> 06:36.800 So you can't really do Analyze without those formats. So that's another reason to start 06:36.800 --> 06:38.320 explaining format two to three. 06:38.400 --> 06:51.680 Um, into was introduced in eight one. You may not have used this one before, but basically 06:51.680 --> 06:59.760 instead of returning the result to you, it puts it in a, in a user variable. That is not compatible 06:59.760 --> 07:04.960 with traditional or the free format format, but it is actually compatible with the JSON version one format. 07:05.520 --> 07:14.320 This is an ice matrix here of compatibility. Um, but really this is this for tooling that needs to 07:14.880 --> 07:24.880 or wants to analyze the output of this on the server side. So you can of course just do explain, 07:24.880 --> 07:29.040 pull back to your application analysis there, but if you want to do some analysis on the server, 07:29.040 --> 07:33.760 this is what you do. We use this a lot in our own testing. If you ever use empty ore, it's 07:34.400 --> 07:40.080 an SQL driven. So we do explain it into a variable and then we use lots of JSON functions 07:40.080 --> 07:44.160 and that to extract all the information we need to record in our test results. 07:46.800 --> 07:55.280 About the JSON port. Yeah. There's no way to set the format on to the explain statement itself. 07:55.280 --> 08:01.600 Is there a reason for that? Let's go back and discuss that later on. Yeah. 08:04.720 --> 08:13.520 For schema was introduced in 82. If you have a query that is not for qualified in, like 08:13.520 --> 08:22.160 have full qualified templates with schema dots table everywhere, then if you are trying to explain a 08:25.040 --> 08:31.600 statement, you have from your application and copied pasted it and we're not in the same schema 08:31.680 --> 08:36.080 that the application was in, then you can use force schema. It's just said that 08:36.880 --> 08:43.600 pretend that this was executed with the current schema of all this. Again, this is for tooling that 08:43.600 --> 08:55.600 has schema name and queries separately. There's one option that's not mentioned here. That is 08:56.160 --> 09:02.800 something introduced in 572. That is explained for connection. For connection based on your 09:02.800 --> 09:06.880 basis, it's a statement because you're explaining something that is already running. There's a 09:06.880 --> 09:16.240 query running in that connection. That is not compatible with anything. For schema is obvious. 09:18.080 --> 09:20.640 It's already executing. There's no point in setting which schema. 09:20.800 --> 09:30.000 In two, it's a bit worse. This is really no reason why intuition works. It's on my list. 09:30.960 --> 09:35.600 The reason it doesn't work today is that we reduce the scope when we introduced into 09:35.600 --> 09:44.160 and we haven't gone around to completing it yet. Analyze, I will get back to why Analyze doesn't work. 09:44.240 --> 09:48.240 I will show you a nice figure explaining why Analyze doesn't work. 09:51.040 --> 09:55.840 That was it. I think that was all the options we have. Can I one think of any options I haven't mentioned? 09:56.640 --> 10:04.320 Like the grammar is quite big, but yeah. For storage, you set a port for the prepared statement. 10:04.320 --> 10:08.960 You're able to use or connect the idea to get something from the 10:09.920 --> 10:16.960 So the question is that for prepared statement, can you get an explain for connection and get 10:16.960 --> 10:23.360 something about the reasonable back? I hope so. I don't think you get something we're doing. 10:25.040 --> 10:31.200 I would really, really expect that it's the normal one. There's no reason why it shouldn't. 10:31.200 --> 10:38.480 I can't test right now, but it should be the same thing. There's no reason it shouldn't. 10:39.360 --> 10:46.880 We can see that, I guess, in the next figure. This is query processing, my goal, 10:46.880 --> 10:54.480 9-0-1, and on, maybe earlier as well. We parse a query, prepare it, so your prepared statement 10:54.480 --> 11:00.160 would prepare and then when you come to execute, you start here again and continue. 11:02.560 --> 11:07.040 It's a bit special in my skill as moment we have two optimizers. If you're in the cloud, 11:07.120 --> 11:10.160 you can use the hypergraph of my server. If you use the heat, 11:10.160 --> 11:13.120 when you're always using the hypergraph of my server, you don't have choice. 11:15.760 --> 11:20.880 And the old optimizer is the one you're used to. The one you're probably using at 11:20.880 --> 11:26.880 moment. It has an old plan format. When we created the hypergraph of my server, 11:26.880 --> 11:31.840 it can express plans that your old optimizer can't. So we created a new plan format. 11:32.000 --> 11:38.480 So the hypergraph of my server has this as its native format. The old optimizer 11:38.480 --> 11:44.800 can transform the plan into that format. The reason for having only one format at this level 11:44.800 --> 11:51.280 is that once we start executing, we take this plan and we generate the iterators that we're 11:51.280 --> 11:55.760 going to iterate over as we execute the query. The operations that we are going to do. 11:55.840 --> 12:00.800 They say one-to-one mapping between the objects in the plan and the objects that we 12:00.800 --> 12:09.360 execute over. It's a very simple mapping there. So by having converting this plan before we go 12:09.360 --> 12:21.840 to execution means that we have only one format to convert there. So traditional and JSON format 12:21.920 --> 12:28.960 are actually just a dump of the old plan format. JSON version one. While JSON version two and 12:28.960 --> 12:35.680 three is a dump of this plan format. We see the new plan format on the optimizer trace. 12:42.240 --> 12:47.600 I don't think you get a plan dump in the optimizer. You don't get actually explained plan in the 12:48.480 --> 12:56.160 off-master trace. But you may add that. That's a good point. I'm thinking about that myself 12:56.160 --> 13:01.600 that we should just dump the plan or anyways the way it is. And then that will be the new one 13:01.600 --> 13:06.880 at this moment. Yeah. I don't think we're going to ever add new stuff using that one. 13:07.840 --> 13:17.280 So this is why they are different. This plan is table oriented. You all have much to 13:17.280 --> 13:22.640 only do left if join. So everything you do is joining in one more table. The hypergraph one 13:22.640 --> 13:27.120 is you can do bush plants. You can join in other things and single tables. So we need something 13:27.200 --> 13:36.880 as operation oriented. Yeah. And this means also that if you use the hypergraph of 13:36.880 --> 13:42.320 mention you can't use these formats at all because it only produces the new plan format which is 13:42.320 --> 13:51.360 explained here. Let's explain analyze. When you do that before you start executing, you create 13:51.520 --> 13:58.080 a plan. When we generate this one to one mapping, we wrap all the iterators in what we call 13:58.080 --> 14:04.560 a timing iterator which counts number of roles in and out and it measures time spent inside 14:04.560 --> 14:10.480 that iterator. So that when the query has been executed, like this is where we generate. 14:10.480 --> 14:16.800 When we have executed, we do the explain. We need a plan and we append all the timing and 14:16.800 --> 14:24.880 row information that we got from these timing iterators. So if you do an explain for connection, 14:26.560 --> 14:31.600 you're coming from this side. You're just from another thread going in and reading these plans 14:31.600 --> 14:36.800 and dumping it in one of these formats. But you're already down here executing iterators. 14:36.800 --> 14:40.880 There's no way for us to go back and add timing iterators around these things. 14:41.120 --> 14:47.920 So we can't do explain analyze for a connection. Then I guess the question would be, 14:47.920 --> 14:54.480 well, why don't we just add timing iterators all the time but they are too expensive to execute today. 14:56.480 --> 15:04.320 I guess row counts could maybe be added for everything without the huge overhead but timing 15:04.320 --> 15:12.080 is actually, it does affect the query execution. So I don't want to add it as it is today. 15:12.080 --> 15:19.280 We need to find a way to make it much cheaper to get the current time stop. 15:24.320 --> 15:33.760 Okay. That is how explain works. Then there's a question of how it could work. 15:34.880 --> 15:44.800 So if we try to look into the future, take my crystal wall and I see something like this. 15:47.520 --> 15:52.960 Don't like these are my thoughts about how this will be or what could happen here. 15:54.240 --> 16:00.880 I can't guarantee anything of this will be implemented or that it's, yeah, the future is a future. 16:01.840 --> 16:10.640 It's hard to predict. But we have this structure today with two optimizers and 16:12.480 --> 16:18.560 basically my team has been taking twice the amount of code that we did before, like two optimizers. 16:18.560 --> 16:26.160 So maybe we will remove this one at some points. The hype grab office is currently cloud only but 16:26.160 --> 16:31.360 if we remove all one of course it will have to be in community edition and enterprise edition as well. 16:34.000 --> 16:41.680 We're still in 9x innovation releases. So we can do a lot of moving around but at some point 16:41.680 --> 16:48.560 we get to 9.7 and we need to decide. And before you ask me it, there hasn't been any decision yet, 16:48.560 --> 16:51.840 so we don't know when this will happen. 16:52.800 --> 16:56.320 When we remove that one, of course the old format's go away. 16:58.320 --> 17:01.280 So you can't use those anymore. 17:05.120 --> 17:17.360 It also means that when you're using the hype grab office, we are getting some, 17:17.360 --> 17:27.600 how's it? We are getting some plans that are different for what you're seeing today. 17:27.600 --> 17:35.840 So if you're, like you could have birthday plans, so options, combinations of operations that 17:36.400 --> 17:40.880 you never have seen before. So if you're trying to parse these JSON plans for instance, 17:41.520 --> 17:47.680 things, or let's say you're just already using JSON version 2 and trying to parse this, 17:47.680 --> 17:52.000 you will see combinations of operations that you've never seen before. The hype grab office 17:52.000 --> 17:59.440 are just things that the old office can't do. Not only Bush and joins but also other operations 17:59.440 --> 18:09.280 that are ordered differently. So talk a bit about this first one already. 18:09.840 --> 18:20.480 We don't really have any dates for removal or all the openmaster. You're on jury tire, okay? 18:20.480 --> 18:29.760 Then that's a good point, Fred. But also traditional or JSON version 1 hasn't been deprecated yet. 18:32.080 --> 18:36.800 Currently I'm thinking if we're going to deprecate them, that will be around the time where we 18:37.280 --> 18:42.480 make the hype grab for optimized available or something like that. That's a good time to 18:42.480 --> 18:51.760 deprecate them formally and say that they will be removed at some points. As that into for connection, 18:52.960 --> 18:58.320 we should just add it. There's no reason why we should. In general, all these 18:59.360 --> 19:05.200 options that should be orthogonal should be independent and be usable wherever it makes sense. 19:06.880 --> 19:20.080 Also, if you are using explain JSON, do you expect more attributes we added? I do expect 19:20.080 --> 19:28.720 that count to 2.0 will be 2.1 before you can probably adapt it as formats. It will count 19:29.360 --> 19:35.520 probably with at the moment it looks like it's counting one change per release. 19:36.400 --> 19:42.080 So at the moment in innovation releases, we are going to add more stuff. We have requests for 19:42.080 --> 19:47.760 from modern uses that we should add stuff and some things we may want to add ourselves. 19:50.080 --> 19:55.200 I'm thinking, personally, I'm also looking into things to add to explain analyze like 19:56.160 --> 20:02.240 did this hash donor sort go to disk that type of thing. So we can actually start to 20:02.240 --> 20:08.720 look a bit more into why a source suddenly took more time than you expected. 20:10.320 --> 20:15.440 Maybe you see how many files it played on disk and how much disk space it used in that type of thing. 20:15.440 --> 20:16.640 More profiling information. 20:18.880 --> 20:23.440 Changing JSON format to 3, so from 3 to 2, that's 2 to 3. 20:25.520 --> 20:30.240 I don't see any reason why we should do that, currently. We have a new format that we are 20:30.240 --> 20:36.480 quite happy with. It's not perfect, but it's pretty good. So don't be afraid of that. 20:40.400 --> 20:46.400 And people are, some people really like the traditional formats. 20:47.280 --> 20:58.400 Questions do we need more formats on that? I'm open to a tabular format if someone has a good 20:58.400 --> 21:02.960 reason why it would actually be. Of course, it would have to be based on the same thing as 21:02.960 --> 21:07.520 it's JSON and 3 format, so it would be a 3 put into a table. 21:10.000 --> 21:16.000 But if it are good reasons, or if there's a model machinery before formats that we should support, 21:16.000 --> 21:26.640 that's a good suggestion. Daniel was up here earlier talking about how we haven't properly 21:26.640 --> 21:33.520 specified the protocol, the documentation and stuff. I think if we create a JSON schema for 21:33.520 --> 21:39.200 explain, at least we're forcing ourselves to maintain it. If we just verify to explain false 21:39.280 --> 21:45.920 JSON schema, we can make sure to keep our documentation somewhat up to date. 21:47.920 --> 21:55.360 So that is some, at least we have a very actually published these JSON schemas for what we 21:55.360 --> 22:00.560 haven't had. It's also a service that's some kind of documentation for what it means. 22:00.640 --> 22:13.520 I have discussed with people before about automatically explaining queries and dumping it somewhere. 22:15.680 --> 22:21.680 The performance scheme is one option. Some people have asked about open telemetry. 22:21.680 --> 22:28.320 I'm kind of open to that as well if you have some kind of way of specifying that. 22:28.560 --> 22:35.280 Basically, we are redirecting explain up to wherever it's necessary, but there's of course a 22:35.280 --> 22:43.120 cost for explain analysis and that analyzes, at least. But if you have requests for how you want 22:43.120 --> 22:49.760 to get your explains, like doing an explain on in production of all queries running there and dumping 22:49.760 --> 22:54.320 in the performance scheme where you can grab them or open telemetry. It sounds like a good idea. It 22:54.400 --> 23:02.160 kind of came from some of you guys. Dumping the explain somewhere, at least in performance 23:02.160 --> 23:07.120 schema, we would also help us a bit with this explain for connection where you could, instead of 23:07.120 --> 23:12.400 grabbing into the brains of the other thread, we can just go to problem scheme on planets. You 23:12.400 --> 23:18.960 don't need to actually do cross thread operations, then we can just read it. So you will not be 23:19.920 --> 23:26.240 discerning thread at all. So that's saying a option we will consider. 23:29.360 --> 23:37.200 So what should you do now? If you're like me, you don't really like the traditional formats 23:37.200 --> 23:44.160 finding hard to read. So switch to tree. That's the only human readable format that works with 23:44.240 --> 23:50.240 the hard graph optimizer as well. So at some point I think you will have to adapt to it. 23:55.360 --> 24:00.160 It also kind of max the execution. The way we execute now is it's very, very close to this 24:00.160 --> 24:05.680 formats. The way we used to execute before was maybe because of the traditional format, but early 24:05.760 --> 24:15.600 NATO series we changed our execution as well. If you're doing any type of automatic 24:16.720 --> 24:22.320 explain stuff, switch to the version 2 format of JSON. We are adding more information there. 24:24.800 --> 24:34.000 It has a version number that you can check. If you do that, be aware that we have semantic 24:34.320 --> 24:40.080 versioning. So check the major version number and expect you have to be added so that the 24:40.080 --> 24:48.960 minor number will be the bumps at least in the innovation releases. I hope that when we get to 24:48.960 --> 25:01.200 97 things will calm down a bit and we will stop doing lots of changes. So yeah, with that I think 25:01.280 --> 25:11.200 I've covered what we are predicting at the moment and I think we'll wrap it up there and 25:11.200 --> 25:19.360 open for questions if there are any. Yeah Daniel. So my school work branch is a facial 25:19.440 --> 25:25.760 explain. Yeah. Any sense for the future for that? I'm not working work branch, but 25:27.760 --> 25:34.560 I know there's some team at Oracle working on a visual explain. I think it is cloud based, 25:34.560 --> 25:42.640 so maybe not for you. But a visual explain is it's not like we are working people that do visual 25:42.720 --> 25:50.640 explain, so for my side it's the JSON format that is the thing and we are very much 25:50.640 --> 25:56.560 accommodating things that are necessary for visual explain. And also if you implement some kind 25:56.560 --> 26:02.640 of visual explain, please look at this thing. There may be new attributes that you don't know 26:02.640 --> 26:07.120 how to show your graph, maybe you should have a way of visualizing that as well. 26:07.760 --> 26:15.520 Yeah, anything else? Make what? What about visual explain in the next code? 26:17.760 --> 26:24.240 That sounds more likely. Thank you. Thank you for reminding me about that. So shall for 26:24.240 --> 26:32.240 be as cold? Yeah. That sounds like a good place for a visual explain. A really good place. 26:32.880 --> 26:41.760 Sorry? Yes, there is a visual explain in the work branch today. It uses this old JSON version 26:41.760 --> 26:50.400 one format that is expected away. That still works, so but if we will not work with the new format, 26:50.400 --> 26:57.280 it will not, for instance, be able to display all the plans that the hyper graph helped 26:57.280 --> 27:09.760 by some companies. Other questions? Yeah. So, I assume you combine the plans to 27:09.760 --> 27:16.560 wear it? No, you can't pin grave lands. It would be some kind of an extension for 27:16.560 --> 27:22.240 explain to say that well, if you have these hints then you might actually get these queries 27:22.560 --> 27:31.520 Oh, that's quite some work to analyze that, I think. But yeah, that's interesting thing. 27:32.880 --> 27:41.040 I have had master students prototyping, queer depending in my role, so we kind of had some 27:41.040 --> 27:46.560 ideas around it. So yeah, it is possible to do, but 27:46.640 --> 27:59.440 that's what used to happen, right? Yeah. Yeah. The problem with pinning is that you pin one plan, 27:59.440 --> 28:06.560 and then maybe your query has several options that would be like depending on the parameters, 28:06.560 --> 28:11.280 do you query? Sometimes you would do an index loop or sometimes you would like an index range 28:11.440 --> 28:18.640 and sometimes you would do a table scan. And if you pin you really want to have the option for 28:18.640 --> 28:25.840 a few alternatives. So, but of course, if you print what you see in an explain, 28:26.880 --> 28:35.440 that could be a way to do that. The problem with that, if you go back to, to, at this thing, 28:36.400 --> 28:45.280 we do explain at this point, but actually the decision is made up here, right? So, up here, 28:45.280 --> 28:50.720 we know why we are choosing the plan, we are picturing. What we're doing is just to dump the plan, 28:50.720 --> 28:58.640 actually this one. So, we would then have to try to remember why we chose what it did. 28:58.640 --> 29:07.360 Yeah, I think you need to optimize the trace, because, well, you saw my presentation at the 29:07.360 --> 29:11.920 pre-fossilum days about how to optimize your works. We throw away a lot of the plans that we don't 29:11.920 --> 29:17.600 use, and we need to kind of know why we didn't choose those. So, I think you need a trace, yeah. 29:20.880 --> 29:25.680 Sorry? That's why you would need a DBA nowadays, still for FB. Yes, yes, you would not have 29:25.760 --> 29:29.760 a work that would be simply DBAs, yeah, yeah. 29:33.200 --> 29:48.800 There, yeah, in the back. Sorry, dumping the, like this. 29:55.680 --> 29:59.040 Yeah, but this is, this is explaining what's going on in this connection at the moment. 30:01.760 --> 30:10.640 Well, yeah, yeah, yeah. Yeah, yeah, yeah, sure, yeah, let's go back there. Yeah, that is 30:10.640 --> 30:15.520 quite easy, because as we see, we have the plan at this point, we just dumping before it's already 30:15.520 --> 30:19.920 executing. I think that would be a good idea, but this is to figure out where to do it. 30:20.720 --> 30:25.760 But I think that's a good idea. Then, of course, this memory uses in performance scheme or for 30:25.760 --> 30:32.320 how many plans you keep, and all that, we need to figure that out. But I think dumping it there is a, 30:33.600 --> 30:40.720 it doesn't cost as much. So, I think that's a good idea. One question. Yeah, we told about adding 30:40.720 --> 30:47.120 these strategies from about removing stuff. For example, I like to just add the cost when 30:48.080 --> 30:54.480 I keep the cost of the queries. And now I need to put out both the Gs of 2 into a variable, 30:54.480 --> 30:59.440 and then that variable is selected, and we will choose on them to just have the cost kind of 30:59.440 --> 31:05.360 the cost. So, the question was, how about removing stuff? We're like, yeah, when you do the 31:05.360 --> 31:10.800 explaining to, you get it, then you have a lot of data on functions to extract it. 31:10.800 --> 31:18.480 Would having a function, predefined function that extracts like the cost of things would be that 31:18.480 --> 31:26.080 we're getting an option for you? Yeah. Like, we can just create a, like, unique, great function, 31:26.080 --> 31:29.920 and then you can store your full contact with the question. Thank you.