‫Hey, guys.
‫One of you asked me a question about the cost unit in the Postgres plan.
‫Here, I made a mistake in the lecture, and I incorrectly refer to it as a millisecond, which is incorrect.
‫Right.
‫And I want to correct that.
‫So let's discuss that a little bit.
‫All right.
‫So this comes from a jasick.
‫I'm sorry if I mispronounce your name, but the question is, like in the video, you said that the
‫cost unit is millisecond, but that's not true.
‫He's right.
‫According to Postgres, the unit is is not in millisecond.
‫It's just a unit defined by the database.
‫Right.
‫And that's that's very critical.
‫And I can agree with him because that I just made a mistake.
‫I just I think I was thinking that it's a millisecond has nothing to do with the millisecond.
‫It's just a cost.
‫It's just a number.
‫Right.
‫So when we look at a plan and it's a good example to go through another question here that Adam actually
‫posted where these costs are actually just values, right?
‫And you might say if it's not millisecond, then what it is, does it really matter?
‫You can think of it as IO, like the cost of IO, right?
‫But it's a unit, right?
‫The what matters is the higher the value, the higher the cost of the query.
‫That's all what matters, right?
‫But it doesn't really equal to the number of milliseconds, right?
‫So if I if I see a value like 4.2 here doesn't mean that it's four is going to take four minutes.
‫Okay?
‫No, no, no, no, no.
‫That's.
‫Yeah, that's all.
‫And I corrected the lecture for that part.
‫Yeah, it just says it's going to cost me four units of whatever this cost.
‫Maybe it's the how many logical Io's I'm going to do, how many CPU cycles is going to take to process
‫these things.
‫So it's like a combination of things and that that is morphed into this unit.
‫What we need to do is this is the first, as I said, like this is the the cost to fetch the first row.
‫This is the cost to fetch the last one.
‫Right.
‫And that's what matters.
‫But and the the second part is like what it actually took me.
‫So it took me way less.
‫Right.
‫So that's part of the estimation versus the actual execution, right?
‫If you see the estimation being way different than this, then we start looking at the statistics.
‫Did we run vacuum or not or did we like, are we up to date?
‫Is the statistics or did we run, analyze, is everything is up to date or not?
‫So this is actually a very critical.
‫And he actually posted a a link here to an article explaining this a little bit more.
‫So apologize for the mistake if that confused you.
‫But yeah, again, as I said, the cost here is unit doesn't matter what it is, the higher value,
‫the higher the cost, the lower the lower the cost.
‫The first entry is the first the cost to get to the first row, you will see that if you do an order
‫by, that, initial value is going to be high because just before the postgres gives you an answer,
‫it has to sort right?
‫And the cost to sort is added on top of everything, right?
‫The cost of the IO not only IO, the cost of the IO to fetch the page, the cost of the CPU like to
‫calculate all this thing and then it's added to the minimum value to get you that right.
‫All right.
‫So to explain this, I, I wrote up two queries here, one with order by and one without order by.
‫I want you to turn on.
‫Is this the one without the order by look at the cost, it's zero.
‫Because for each table, because I have partitions on this table, I'm doing select star from grades.
‫Right?
‫So the cost to fetch the first row is zero.
‫There is absolutely no cost because it's literally the first thing I'm going to do, right?
‫So what's happening here is you can see the cost is zero here because we're reading all the partitions
‫and then finally we're going to do an append, right, and return the first row.
‫The cost to return the first row after reading all the partitions, probably not a good idea to do the
‫partition because it's a little bit complex, but you guys get it.
‫You guys get it right.
‫So the the cost to get the first row off of all these partitions after we read all of them is zero.
‫There's nothing.
‫There's no cost.
‫Because literally whatever the order was that we got, just pick the first one, which we have like
‫a pointer to.
‫So there is no cost to fetch the first one.
‫Right.
‫The cost to get the last one is 21.
‫But take this with an order by on G.
‫I'm just going to I said order by the grade.
‫So here again if you notice that the cost to fetch the first rows here are zero.
‫Why?
‫Because we're not really technically ordering for each query on the partition.
‫We're just reading it raw, right?
‫But then after we appending all rows, the cost to append is nothing.
‫Right to first fetch one.
‫But the cost, the last append, the last one is that's the most cost.
‫Then we apply the sort and look at that.
‫The cost to give you the first row after the sort is 70.
‫It's not 70 millisecond.
‫Again, it's just 70 as a value here, right?
‫So that's a higher value.
‫That means it's of course, 70 is greater than zero.
‫As a result that it's a lot.
‫Right.
‫And the cost to give you the last after that, just three costs after that.
‫So 73.
‫Right.
‫So that's because we don't have much rows, but the cost to give you that.
‫So let's be very careful we're having order by because that.
‫Right.
‫That is the cost to give you the first row, especially if you have like a if you give a query, the
‫latency is here.
‫Right.
‫What is the especially if you're like fetching the first limit, like give me the first one row or two
‫rows.
‫Doesn't matter if if the if the planner has to do a query and has to sort that cost is has to be done
‫first, then before the select.
‫Right.
‫All right, guys, that's it for me today.
‫Hope you enjoyed this lecture.
‫I wanted to clarify that cost parameter and just hitting in the nail.
‫Correct.
‫My mistake.
‫See you in the next one.