1
00:00:00,090 --> 00:00:01,050
‫Hello, everybody.

2
00:00:01,080 --> 00:00:11,670
‫It is October 2021, and I thought it might be interesting for I to go through your fantastic questions

3
00:00:11,670 --> 00:00:20,400
‫on this course introduction to database engineering as you ask great questions and kind of go through

4
00:00:20,790 --> 00:00:25,200
‫some of them that I again have picked out and then answer them in details.

5
00:00:25,320 --> 00:00:28,590
‫I try as much as possible to go through this question and answer them.

6
00:00:28,990 --> 00:00:36,150
‫You guys ask fantastic questions, but I thought some of these questions you it's very hard to answer

7
00:00:36,150 --> 00:00:36,660
‫in tax.

8
00:00:36,660 --> 00:00:46,740
‫So it might be interesting to make a new lecture called Q&A and answer some of these questions in detail.

9
00:00:46,770 --> 00:00:53,400
‫I'm going to if you like these kind of lectures, let me know in the common discussions.

10
00:00:53,400 --> 00:00:55,320
‫I guess you can have discussions in this lecture.

11
00:00:55,620 --> 00:01:02,310
‫Let me know if you want more, and maybe I'll get to do it in a couple of months about just jump into

12
00:01:02,310 --> 00:01:06,400
‫it and see who try to answer some of these questions.

13
00:01:06,480 --> 00:01:09,300
‫So here's a question from Constantinos.

14
00:01:09,300 --> 00:01:16,470
‫I hope I pronounce your name right and on the getting started with indexing lecture on our introduction

15
00:01:16,470 --> 00:01:22,530
‫to and drink or getting different results with explain, analyze high dosing and saying thank you for

16
00:01:22,530 --> 00:01:28,800
‫the direct and comprehensive explanation you get every time you're welcome running, explain analyze

17
00:01:28,800 --> 00:01:32,640
‫using the exact same syntax with your two queries.

18
00:01:32,640 --> 00:01:39,210
‫I get different results for the first explain analyze select ID from employees where ID equal two thousand

19
00:01:39,510 --> 00:01:41,880
‫I get a value of when he fetches.

20
00:01:42,240 --> 00:01:47,040
‫For the latter, I get none effectively right.

21
00:01:47,040 --> 00:01:53,400
‫And then so so they are effectively saying that you're I'm getting different results with every time

22
00:01:53,400 --> 00:02:01,800
‫I execute non the results I get every I get, I get different timings when I execute this query twice.

23
00:02:02,130 --> 00:02:04,260
‫And let's explain a little bit here.

24
00:02:04,260 --> 00:02:06,600
‫What do we mean by heap features first?

25
00:02:06,870 --> 00:02:11,700
‫So when you execute a query and specifically in Postgres, right?

26
00:02:14,070 --> 00:02:20,910
‫And that query goes through a path that is.

27
00:02:22,510 --> 00:02:27,190
‫Exclusively searching the index, which is index only scan.

28
00:02:27,580 --> 00:02:30,820
‫I talked about that and one of the lectures index only scans.

29
00:02:31,720 --> 00:02:37,240
‫That means that it should only go to the index structure, right?

30
00:02:37,570 --> 00:02:43,390
‫Because we know that there are two structures that is the heap or the entire table worth of data.

31
00:02:43,750 --> 00:02:51,700
‫And there is another data structure called the index that has subset and pointers to the heap with the

32
00:02:51,700 --> 00:02:52,540
‫actual content.

33
00:02:52,840 --> 00:02:59,020
‫So if you're only doing an index only scan, you should only be looking into this structure, which

34
00:02:59,020 --> 00:03:00,550
‫is the index structure, right?

35
00:03:00,910 --> 00:03:06,910
‫At most queries that are index scans, normal scans, they go to the index, find what they want and

36
00:03:06,910 --> 00:03:13,840
‫jump exactly to the page or the block in the table that has the data and pull it up, right?

37
00:03:14,110 --> 00:03:17,470
‫If you don't have an index, you have to scan the heap for the entire table.

38
00:03:18,210 --> 00:03:20,380
‫Right, that's that's how basic indexing works.

39
00:03:20,740 --> 00:03:29,270
‫He pitches tells us that, yeah, I did an index only scan, but I had to go to the heap to do that.

40
00:03:29,320 --> 00:03:34,960
‫So this is kind of contradictory because hey, if if all the resources index X already jumping in the

41
00:03:34,960 --> 00:03:38,140
‫heap, you jump Postgres keeps these things going.

42
00:03:38,240 --> 00:03:45,970
‫Hence, that tells you if a row is deleted, updated or modified.

43
00:03:46,330 --> 00:03:54,060
‫So you see when when I delete, for example, a row in Postgres or an insert or even updater row you,

44
00:03:54,250 --> 00:04:00,310
‫we create a new version of this rule because both Clarissa's and MVC designed a multi-year concurrency

45
00:04:00,310 --> 00:04:06,310
‫control, which means that we also update the index to update the entry.

46
00:04:06,670 --> 00:04:13,360
‫All right, that that that points to our tuple because the index also points to the table because you

47
00:04:13,360 --> 00:04:14,080
‫touch the row.

48
00:04:14,260 --> 00:04:17,080
‫We have to update the index to point to the new version, right?

49
00:04:17,500 --> 00:04:28,410
‫But we also also keep the old version because some other transactions are also reading, right?

50
00:04:28,840 --> 00:04:36,280
‫The older running transaction need to make sure that the rule is is running and alive as a result.

51
00:04:36,880 --> 00:04:46,660
‫So because of this, all of a sudden now transactions need to make sure that is the role I'm looking

52
00:04:46,660 --> 00:04:50,640
‫at deleted or updated or it is or is.

53
00:04:50,650 --> 00:04:51,610
‫Is it alive?

54
00:04:52,420 --> 00:04:56,530
‫To answer this question, is it alive at that bits?

55
00:04:56,650 --> 00:04:57,700
‫Is it alive?

56
00:04:58,120 --> 00:04:59,260
‫Can I see it?

57
00:04:59,710 --> 00:05:01,210
‫Is these kind of bits?

58
00:05:01,210 --> 00:05:03,310
‫The hint bits are stored in the heap.

59
00:05:03,760 --> 00:05:05,740
‫And as a result, you see these jumps.

60
00:05:06,100 --> 00:05:08,230
‫How do you get rid of these jumps?

61
00:05:08,650 --> 00:05:09,970
‫Well, two solutions.

62
00:05:10,360 --> 00:05:17,260
‫If you have long running transactions, then you will definitely see these jumps because these jumps

63
00:05:17,260 --> 00:05:27,640
‫means that there are transactions are very old, very long running, and they they are reading old data

64
00:05:28,270 --> 00:05:30,220
‫that we cannot get trade off.

65
00:05:30,850 --> 00:05:36,400
‫That means, hey, from time to time, I'm going to have to jump to the heap to at to check if this

66
00:05:36,400 --> 00:05:37,830
‫rule is visible or not.

67
00:05:37,840 --> 00:05:45,100
‫But most of the time, if you don't have any running transactions, that means you can freely clean

68
00:05:45,100 --> 00:05:51,970
‫up these old rolls and we can freely avoid going to the heap to see if this rule is alive or not.

69
00:05:52,330 --> 00:05:53,470
‫Run vacuum.

70
00:05:53,680 --> 00:05:58,510
‫I talk about vacuuming and allies and all this stuff in many lectures on this course, right?

71
00:05:58,840 --> 00:06:05,530
‫So if you don't vacuum after each after all the updates, then you should get consistent results as

72
00:06:05,530 --> 00:06:07,090
‫of the timing, right?

73
00:06:07,960 --> 00:06:14,020
‫They did mention that the timing is like point zero zero four seven millisecond versus point one seven

74
00:06:14,020 --> 00:06:14,650
‫milliseconds.

75
00:06:16,120 --> 00:06:22,030
‫This is expected because the timing you only have to worry about times if it's more than, I don't know,

76
00:06:22,750 --> 00:06:24,550
‫ten milliseconds, right?

77
00:06:24,880 --> 00:06:26,230
‫12 milliseconds.

78
00:06:26,530 --> 00:06:26,860
‫Right.

79
00:06:27,220 --> 00:06:28,210
‫Six milliseconds.

80
00:06:28,210 --> 00:06:34,750
‫But if it's less than a millisecond, there is so many variables with the hardware, you know, then

81
00:06:34,750 --> 00:06:37,750
‫you getting into really low level stuff.

82
00:06:37,750 --> 00:06:40,720
‫And this is really not worth going through you.

83
00:06:40,720 --> 00:06:43,620
‫Only if you seeing 100 millisecond to one.

84
00:06:43,660 --> 00:06:47,230
‫That's where you actually optimize point one point two.

85
00:06:47,650 --> 00:06:49,540
‫It's really not deterministic.

86
00:06:49,750 --> 00:06:50,890
‫Depends on the CPU.

87
00:06:50,890 --> 00:06:52,420
‫Depends on the hardware that happens.

88
00:06:52,420 --> 00:07:00,010
‫And there's other processes running with Postgres, your machine probably having multiple processes

89
00:07:00,010 --> 00:07:01,960
‫that is hogging your CPU.

90
00:07:02,240 --> 00:07:02,390
‫Right.

91
00:07:02,620 --> 00:07:04,230
‫So that's kind of answers this question.

92
00:07:04,240 --> 00:07:05,170
‫Let's pick another one.

93
00:07:05,230 --> 00:07:12,970
‫So this is another interesting question from Ihab Ahmed on the SIDBI practice examples lecture, right?

94
00:07:13,000 --> 00:07:17,000
‫Is durability versus persistent Hyson in 29 minutes.

95
00:07:17,020 --> 00:07:21,550
‫So you said that Origi's doesn't offer durability because of course it is.

96
00:07:22,080 --> 00:07:25,600
‫In-memory database lives in rum if electricity goes down.

97
00:07:25,620 --> 00:07:30,030
‫Data is lost and also you, you said, but it has persistence.

98
00:07:30,330 --> 00:07:32,730
‫I need to know, what do you mean by that?

99
00:07:33,090 --> 00:07:34,560
‫And I want to understand your bird.

100
00:07:34,560 --> 00:07:37,080
‫Well, what is the difference with durability and persistence?

101
00:07:37,560 --> 00:07:39,950
‫They are effectively very, very similar, right?

102
00:07:39,950 --> 00:07:47,610
‫I might have confused you in that lecture, but let's try to kind of clarify this.

103
00:07:48,210 --> 00:07:50,220
‫So we're going to come to write this.

104
00:07:50,220 --> 00:07:59,340
‫But let's explain the concept of persistence to persist is to right to a specific location and have

105
00:07:59,340 --> 00:08:01,360
‫it there, right?

106
00:08:01,560 --> 00:08:06,240
‫So like if you write to a desk, it's persisted to desk, right?

107
00:08:06,240 --> 00:08:15,900
‫And then that means if you turn off the electricity and you turn it back on, that that charge will

108
00:08:15,900 --> 00:08:16,770
‫still be there.

109
00:08:16,770 --> 00:08:24,410
‫Whether you're using magnetic work as a hard drive or a charge in case of as is the the data is there

110
00:08:24,420 --> 00:08:25,740
‫that's called persistence.

111
00:08:26,040 --> 00:08:36,720
‫Now durability is is a term that database uses and the idea of if I write and if I said I started the

112
00:08:36,730 --> 00:08:43,470
‫transaction, I did a bunch of queries and I wrote a few things and inserted that update of the update.

113
00:08:43,950 --> 00:08:45,150
‫And then I said, commit.

114
00:08:45,900 --> 00:08:49,110
‫My transaction is durable if.

115
00:08:51,150 --> 00:08:54,300
‫After the comment, I tell you it succeeded.

116
00:08:55,490 --> 00:09:02,720
‫If after that, after a millisecond of you telling me that the transaction committed successfully,

117
00:09:03,200 --> 00:09:11,300
‫I can turn the database off completely, I can unplug the computer and plug it back in and start the

118
00:09:11,300 --> 00:09:13,040
‫database, and the data should be there.

119
00:09:13,400 --> 00:09:20,720
‫Now, the durability has to use persistence in order to obviously have the data on right.

120
00:09:21,470 --> 00:09:23,510
‫And that's that's that's basically what it is.

121
00:09:24,260 --> 00:09:29,870
‫And now read this is durable.

122
00:09:31,970 --> 00:09:38,620
‫But it depends on the type of durability option that you pick.

123
00:09:38,630 --> 00:09:42,500
‫And I don't believe I talked about this in detail, but here is free.

124
00:09:42,500 --> 00:09:47,510
‫Like you guys, the idea of IS has, I think, three formats.

125
00:09:47,690 --> 00:09:56,300
‫Effectively, right there is the snapshot format where asynchronously when you issue right, these rights

126
00:09:56,300 --> 00:10:02,480
‫actually, and this goes to memory first and they will commit immediately and they say here.

127
00:10:03,430 --> 00:10:10,390
‫They wrote the riot was successful because it was successful writing to the RAM, to the memory, right?

128
00:10:10,760 --> 00:10:13,690
‫Doesn't I say RAM, but memory is.

129
00:10:14,440 --> 00:10:16,120
‫Is there a vast right?

130
00:10:16,120 --> 00:10:18,940
‫Because could be virtual memory, right?

131
00:10:19,510 --> 00:10:21,100
‫Could be memory on disk?

132
00:10:21,100 --> 00:10:24,670
‫That's kind of a memory right at the temporal thing.

133
00:10:24,940 --> 00:10:27,960
‫RAM is the random access memory, the slot Needham's.

134
00:10:29,230 --> 00:10:35,470
‫And when I write that you get back, commit successfully.

135
00:10:35,590 --> 00:10:36,070
‫But.

136
00:10:37,170 --> 00:10:41,010
‫In that case, if you lose power, you lost your data.

137
00:10:41,430 --> 00:10:43,590
‫But red is what they do with the snapshot is.

138
00:10:44,820 --> 00:10:49,710
‫After a second or two, they take the entire memory and they flush it to disk.

139
00:10:49,920 --> 00:10:57,780
‫They actually persisted to disk, so it is only true that you lose your data exactly after their second

140
00:10:58,080 --> 00:10:58,380
‫right.

141
00:10:58,470 --> 00:11:06,870
‫If the asynchronous process fails to try to disk and you lose power, then Reuters will lose your data.

142
00:11:07,200 --> 00:11:15,570
‫But if you write, write, your transactions succeeded to it, writing to the RAM and then that read

143
00:11:15,570 --> 00:11:22,890
‫is asynchronous process kicks in and then snapshot showed the RAM to disk, and then it failed, the

144
00:11:22,890 --> 00:11:23,660
‫note read.

145
00:11:23,660 --> 00:11:28,200
‫This is actually persistent and durable because hey, did lose your data.

146
00:11:28,560 --> 00:11:34,290
‫If it happened in that X amount of seconds and you can configure, then you will lose your data.

147
00:11:34,330 --> 00:11:41,910
‫So, yeah, it is durable, but there is an option that you can also now you this is the fastest right

148
00:11:41,910 --> 00:11:42,480
‫option.

149
00:11:42,840 --> 00:11:50,990
‫There are many other options and readiness that has stronger durability because that that was like a

150
00:11:51,060 --> 00:11:57,180
‫weaker durability or the stronger durability option in what is called aos append only file.

151
00:11:57,180 --> 00:11:59,280
‫I think I talked about it and answer here as well.

152
00:11:59,760 --> 00:12:09,120
‫So the idea here is as you persist analysis, as you commit your transaction, we write it to the RAM

153
00:12:09,120 --> 00:12:13,380
‫and also we write it to an append only file called this a redo log.

154
00:12:13,620 --> 00:12:17,940
‫Some people call it the wall and traditional relational databases.

155
00:12:17,940 --> 00:12:27,120
‫We call the wall the right to head log and only one that succeeds writing to the wall, which is the

156
00:12:27,120 --> 00:12:30,780
‫Journal, which is on disk.

157
00:12:31,230 --> 00:12:41,250
‫Then we actually say sexy, and this is this is effectively a log of the metadata entries itself.

158
00:12:41,250 --> 00:12:41,870
‫The X.

159
00:12:41,940 --> 00:12:49,650
‫The actual description of the data includes the data as well, but doesn't have the full data structure

160
00:12:49,650 --> 00:12:50,580
‫of that data.

161
00:12:50,730 --> 00:12:51,390
‫That makes sense.

162
00:12:51,900 --> 00:12:55,350
‫Like if you're writing into an index, write the index itself.

163
00:12:55,350 --> 00:12:56,640
‫It's complex, right?

164
00:12:57,240 --> 00:13:05,760
‫But so the log will have an entry, said write X to the index blah, right?

165
00:13:06,000 --> 00:13:12,090
‫So this is always compact, but writing for the actual indexes has to be trees and you have to update

166
00:13:12,090 --> 00:13:14,460
‫many, many locations and stuff like that, right?

167
00:13:14,940 --> 00:13:16,500
‫So it's not a one to one, always.

168
00:13:17,010 --> 00:13:19,080
‫So that's the only file.

169
00:13:19,080 --> 00:13:27,180
‫And Redis has a stronger durability, and it's it's one to one exactly identical to the to the relational

170
00:13:27,180 --> 00:13:27,540
‫database.

171
00:13:27,540 --> 00:13:34,710
‫So yeah, I this is actually strongly durable if you chose that option, but it's going to be slow in

172
00:13:34,710 --> 00:13:40,860
‫rights because now you're writing to disk with every with every transaction.

173
00:13:41,160 --> 00:13:41,520
‫Right?

174
00:13:42,510 --> 00:13:45,990
‫That's why this is only fast because it's writing to memory, right?

175
00:13:46,410 --> 00:13:48,270
‫But there is always a choice.

176
00:13:48,390 --> 00:13:55,680
‫If you always if you took a snapshot, you can choose both it off and a snapshot as well.

177
00:13:56,760 --> 00:14:00,140
‫To get the best of the award, you choose snapshot.

178
00:14:00,150 --> 00:14:08,040
‫Your rights are fast, but you might lose your data might if that happened, which is very rare, that

179
00:14:08,040 --> 00:14:08,790
‫it can happen.

180
00:14:09,300 --> 00:14:15,720
‫If you're willing to take this chance, you can or you can have your rights being slow, but you have

181
00:14:15,720 --> 00:14:16,770
‫higher durability.

182
00:14:16,890 --> 00:14:17,820
‫The option is yours.

183
00:14:17,850 --> 00:14:21,030
‫That's why I like this choice and release.

184
00:14:21,030 --> 00:14:24,090
‫You don't have this choice in other Postgres or MRGO.

185
00:14:24,090 --> 00:14:25,650
‫I don't give you this durability choice.

186
00:14:25,830 --> 00:14:26,850
‫Let's go to the next question.

187
00:14:26,880 --> 00:14:35,910
‫So there's another question from Tanner shared on their shared versus exclusive lock lecture the lifecycle

188
00:14:35,910 --> 00:14:37,530
‫of a lock in a transaction.

189
00:14:37,530 --> 00:14:43,560
‫If we update a roll during updation, the rule acquires an exclusive lock.

190
00:14:44,010 --> 00:14:47,310
‫Does it have an exclusive lock until they come into the transaction?

191
00:14:47,310 --> 00:14:52,170
‫So the question is what is the lifecycle of a lock, right?

192
00:14:52,530 --> 00:14:57,240
‫So this difference from one database to another, but the idea is.

193
00:14:59,080 --> 00:15:06,730
‫If I update one roll right, then that rule is locked exclusively.

194
00:15:07,030 --> 00:15:14,280
‫Assuming the database supports roll level locking, not all database supports that.

195
00:15:14,590 --> 00:15:23,770
‫Some databases, actually when you want to lock one rule, it locks the entire table because it says,

196
00:15:23,770 --> 00:15:24,760
‫Hey, it's easier.

197
00:15:24,760 --> 00:15:32,190
‫It's cheaper to lock the entire table instead of locking one rod because assuming you update a thousand

198
00:15:32,200 --> 00:15:35,590
‫drawers to maintain thousand locks.

199
00:15:35,950 --> 00:15:37,960
‫Yeah, that's what most databases do.

200
00:15:38,290 --> 00:15:41,620
‫Sequels, or perhaps does that actually pose?

201
00:15:41,680 --> 00:15:47,230
‫Because does it differently and maintains the lock in the table itself, like Oracle does a different

202
00:15:47,230 --> 00:15:49,270
‫every database does it differently.

203
00:15:49,480 --> 00:15:50,980
‫But yet locks are expensive.

204
00:15:51,040 --> 00:15:58,510
‫So as you update human DNA lock and when the transaction rolls back or commit, we release that look.

205
00:15:58,690 --> 00:16:09,280
‫And the reason we we obtain an exclusive lock on the row itself when you added it so that nobody else

206
00:16:09,700 --> 00:16:17,180
‫actually tries to change it because we don't want the transaction to change it sometimes.

207
00:16:17,180 --> 00:16:20,590
‫So I don't want another transaction to even read it right there.

208
00:16:20,620 --> 00:16:22,850
‫Read this version of the roll, right?

209
00:16:24,010 --> 00:16:26,740
‫The word exclusive here is a little bit harsh.

210
00:16:27,130 --> 00:16:32,290
‫Exclusive means don't even allow reading it right.

211
00:16:33,190 --> 00:16:35,290
‫This depends on the type of database.

212
00:16:35,290 --> 00:16:42,610
‫Again, some databases, uh, prevents you from updating it, but allows you to read it in some database.

213
00:16:42,610 --> 00:16:47,080
‫Some databases doesn't even have this concept like both because it has multiple versions.

214
00:16:47,470 --> 00:16:49,540
‫Hey, I'm updating this zero.

215
00:16:49,780 --> 00:16:51,400
‫I create a new version locked in.

216
00:16:52,030 --> 00:16:57,010
‫The old one is is free to be read, right?

217
00:16:57,020 --> 00:16:58,030
‫You can still read it.

218
00:16:58,060 --> 00:17:04,000
‫So once you affirmatively roll back or commit the transaction, this lock has gone plain.

219
00:17:04,000 --> 00:17:07,360
‫Lock management is very, very expensive effectively.

220
00:17:08,080 --> 00:17:11,740
‫So, yeah, that's in a nutshell the lifecycle of a lock effectively.

221
00:17:11,740 --> 00:17:15,040
‫But there are many, many types of lock up that answers that question.

222
00:17:15,070 --> 00:17:19,470
‫So it's also this final question index scan versus index only scans.

223
00:17:19,780 --> 00:17:26,620
‫Krishna asks What exactly is the difference between creating an index on columns directly versus including

224
00:17:26,620 --> 00:17:28,150
‫none key columns, right?

225
00:17:28,600 --> 00:17:35,890
‫So they're they're they're they're asking the difference between, Hey, what if I created two indexes

226
00:17:35,890 --> 00:17:43,020
‫here by a create index ID on the ID field and creating another index on the name field.

227
00:17:43,060 --> 00:17:44,950
‫So I have two indexes verses.

228
00:17:44,950 --> 00:17:49,420
‫I create one index on the IED field and I include the name.

229
00:17:50,110 --> 00:17:53,080
‫There is a huge difference between the first of all this.

230
00:17:53,650 --> 00:17:57,580
‫You have two indexes, so you have two data sections, so you have to be trees, right?

231
00:17:57,910 --> 00:18:05,140
‫So twice the amount of not really stored different storage, but twice the amount of data structures,

232
00:18:05,530 --> 00:18:05,860
‫right?

233
00:18:06,190 --> 00:18:15,310
‫And well, while the second is you creating one index and in that index is keyed on the ID.

234
00:18:16,060 --> 00:18:24,520
‫But you are including with each entry, the name, the corresponding name value not to search for,

235
00:18:24,910 --> 00:18:26,380
‫but to include it.

236
00:18:26,680 --> 00:18:31,720
‫So that means if you search by the ID, you the B3, the index will be used to search on the.

237
00:18:32,560 --> 00:18:34,210
‫And for free.

238
00:18:34,510 --> 00:18:39,370
‫When you find the I.D., you can get the name for free without getting to the heap to the table itself,

239
00:18:39,550 --> 00:18:40,990
‫to which the name column.

240
00:18:41,650 --> 00:18:50,950
‫But if you search by the name column, this will not hit the index because the name column is not indexed

241
00:18:51,280 --> 00:18:55,050
‫on the first example that you showed here when you search by the name.

242
00:18:55,060 --> 00:18:58,510
‫Yet there is an index and you can search by the name right?

243
00:18:58,840 --> 00:19:00,790
‫It's a it's a little bit of a different thing.

244
00:19:00,790 --> 00:19:08,620
‫And there's another way where you have a composite right index, where you have one index with two values

245
00:19:08,830 --> 00:19:17,050
‫where you can search by the ID and you can search by the ID and the name, but you can search by the

246
00:19:17,050 --> 00:19:22,610
‫name only as well because the name is on the right side of the composite key.

247
00:19:22,630 --> 00:19:24,100
‫I talked about that in the lecture.

248
00:19:24,370 --> 00:19:27,880
‫All right, guys, let's end up here at just answering for questions.

249
00:19:28,120 --> 00:19:29,650
‫It took us a long time.

250
00:19:30,250 --> 00:19:33,010
‫Let me know if you enjoy these kind of Q&A.

251
00:19:33,370 --> 00:19:34,390
‫I'm going to see you in the next one.

252
00:19:35,500 --> 00:19:36,250
‫Enjoy the course.

253
00:19:36,730 --> 00:19:37,000
‫Goodbye.