1
00:00:00,260 --> 00:00:07,840
‫To spend a few moments to discuss the difference between optimistic concurrency control and pessimistic

2
00:00:08,160 --> 00:00:14,850
‫currents, concurrency control, so optimistic because of control and pessimistic concurrency control

3
00:00:14,850 --> 00:00:16,500
‫is so critical.

4
00:00:16,830 --> 00:00:27,720
‫It's it's basically the atomic level of how you pick which path decides basically what database you're

5
00:00:27,720 --> 00:00:28,230
‫going to run.

6
00:00:28,770 --> 00:00:30,080
‫Let's discuss that today.

7
00:00:31,530 --> 00:00:34,900
‫I'm going to talk about optimistic versus pessimistic.

8
00:00:36,990 --> 00:00:47,340
‫If you don't want to support any control at all, you want to build a single user database that nobody

9
00:00:47,340 --> 00:00:47,930
‫else is going to add.

10
00:00:47,990 --> 00:00:53,070
‫Just one single user is going to slam and edit this stuff, right.

11
00:00:54,000 --> 00:00:55,950
‫That is no multi users.

12
00:00:56,130 --> 00:01:04,320
‫There is no ability to to do transactions and there is no ability to do isolation.

13
00:01:04,410 --> 00:01:10,020
‫You know, you're not, you know, trying to isolate anyone from your reads all rise, for that matter.

14
00:01:10,530 --> 00:01:14,810
‫So if you do that, if you don't do that, you don't have to worry about anything.

15
00:01:14,820 --> 00:01:15,990
‫You kind of click off this video.

16
00:01:16,410 --> 00:01:24,750
‫But if you do, which most databases do post physical Mongo DB, most databases need to support multiuser

17
00:01:25,020 --> 00:01:27,460
‫and don't think of multiuser as Web users.

18
00:01:27,480 --> 00:01:33,160
‫We're talking about multiple transactions that doesn't have to come from the same user.

19
00:01:34,230 --> 00:01:37,170
‫Let's say it say there are a thousand viewers.

20
00:01:37,980 --> 00:01:45,150
‫Those are technically multi user, but to the database they might come from the same database instance

21
00:01:45,150 --> 00:01:45,590
‫user.

22
00:01:45,930 --> 00:01:50,440
‫You're not going to create a different database user for every single web interface, right?

23
00:01:50,460 --> 00:01:51,200
‫You don't do that.

24
00:01:51,870 --> 00:01:57,100
‫So but but the idea of concurrency is there is the key here.

25
00:01:57,600 --> 00:02:01,620
‫And how do you forget about all this mumbo jumbo that we're talking about?

26
00:02:01,620 --> 00:02:03,540
‫Concatenating control and all this stuff?

27
00:02:04,860 --> 00:02:06,940
‫How would you stop and think about it?

28
00:02:07,290 --> 00:02:13,170
‫Forget about all the papers that I've been writing about database systems and take this question and

29
00:02:13,170 --> 00:02:27,630
‫try to answer it yourself, how would you prevent someone from changing a value that you just change

30
00:02:27,630 --> 00:02:29,090
‫and you want to persist?

31
00:02:29,460 --> 00:02:30,430
‫How do you do that?

32
00:02:30,900 --> 00:02:34,540
‫So you started a transaction and you changed some value.

33
00:02:35,250 --> 00:02:41,070
‫How do you then prevent someone else from changing that value?

34
00:02:41,610 --> 00:02:43,160
‫Because that's dangerous, right?

35
00:02:44,430 --> 00:02:49,260
‫Unless that value is committed and the other transaction starts.

36
00:02:50,010 --> 00:02:55,400
‫It should always see that latest change and then have the idea of changing it.

37
00:02:56,160 --> 00:03:03,320
‫If you allow this update to happen, then there is this thing as called a lost update.

38
00:03:03,330 --> 00:03:06,420
‫You you made a change, but you turn around and it's lost.

39
00:03:07,890 --> 00:03:14,750
‫There's a lot of misconception about this because a lost update only happens in the same transaction.

40
00:03:15,300 --> 00:03:17,100
‫You wrote something, right?

41
00:03:17,100 --> 00:03:20,520
‫You didn't commit yet any attempt to read it and use all their.

42
00:03:22,580 --> 00:03:27,020
‫That is dangerous because basically it causes corruption.

43
00:03:28,520 --> 00:03:31,030
‫This is not the last update that I'm going to describe.

44
00:03:31,490 --> 00:03:39,560
‫You start a transaction, you change a field value, you commit and then you read it and it's not there.

45
00:03:41,270 --> 00:03:43,270
‫That is not a lost transaction.

46
00:03:43,330 --> 00:03:43,640
‫Why?

47
00:03:43,640 --> 00:03:48,830
‫Because after you commit, someone else could have started the transaction, changed the field and then

48
00:03:48,830 --> 00:03:53,700
‫committed and then you read that committed value that that someone that transaction that changed.

49
00:03:53,990 --> 00:03:58,340
‫So that's technically not a loss of Diso measuring loss, but it is very hard.

50
00:03:58,880 --> 00:04:01,520
‫But effectively, it is.

51
00:04:01,520 --> 00:04:08,440
‫It is almost like you're you're just reading this transaction history.

52
00:04:08,450 --> 00:04:08,700
‫Right.

53
00:04:09,470 --> 00:04:15,650
‫So how would you build a system that prevents these kind of things?

54
00:04:15,800 --> 00:04:22,030
‫A classic example is to use something called locking.

55
00:04:23,270 --> 00:04:25,910
‫Hey, I'm updating this row.

56
00:04:26,930 --> 00:04:28,100
‫I'm going to lock it.

57
00:04:28,610 --> 00:04:29,210
‫Why?

58
00:04:30,380 --> 00:04:38,150
‫Because I don't want anyone to change that value as long as my transaction is running.

59
00:04:38,690 --> 00:04:40,160
‫I want to go my own thing.

60
00:04:40,160 --> 00:04:43,670
‫I'm doing update to other fields, to other columns, to other tables.

61
00:04:44,570 --> 00:04:46,720
‫But by that value shouldn't really change.

62
00:04:46,730 --> 00:04:49,010
‫As long as you touched it, you changed it.

63
00:04:50,090 --> 00:04:52,500
‫You don't want it to change during your transaction.

64
00:04:52,520 --> 00:04:54,310
‫That's the definition of lost update, right?

65
00:04:55,510 --> 00:05:02,890
‫How do you do that if you write that about you, you can say, look, that you can tell the database

66
00:05:02,890 --> 00:05:10,690
‫to lock it and by definition, this is a global concept that tells any other transaction that says,

67
00:05:10,870 --> 00:05:19,180
‫hey, if another transaction attempt to write to this law, right to this row, that particular field

68
00:05:19,210 --> 00:05:20,800
‫we're talking about roads, not columns.

69
00:05:20,810 --> 00:05:27,910
‫You're right, there is no concept of column based block, although it's fun.

70
00:05:27,910 --> 00:05:32,560
‫But there isn't there there's only road blocks for simplicity.

71
00:05:32,570 --> 00:05:34,660
‫You can build something like that, but it's so expensive.

72
00:05:35,740 --> 00:05:37,420
‫So I like the road.

73
00:05:37,510 --> 00:05:41,720
‫So other person want to update another field of the same road.

74
00:05:41,850 --> 00:05:42,640
‫They can't do that.

75
00:05:43,570 --> 00:05:45,670
‫And you can define what that means.

76
00:05:46,780 --> 00:05:48,100
‫Can't what does that mean?

77
00:05:48,730 --> 00:05:55,450
‫You can fail or you can make them wait.

78
00:05:57,530 --> 00:05:58,700
‫And that's what locks do.

79
00:06:00,050 --> 00:06:00,500
‫What?

80
00:06:01,840 --> 00:06:09,010
‫This model is called pessimistic because you are so pessimistic that you don't trust anyone.

81
00:06:09,790 --> 00:06:15,850
‫You just say, I'm going to lock this thing and I'm just going to prevent anyone from changing this

82
00:06:15,850 --> 00:06:16,090
‫thing.

83
00:06:16,300 --> 00:06:24,220
‫And I don't care of anyone didn't because someone you might you might just go through the whole transaction

84
00:06:24,220 --> 00:06:26,860
‫and nobody actually try to touch your.

85
00:06:28,240 --> 00:06:28,950
‫Roll, right?

86
00:06:29,950 --> 00:06:35,790
‫But do you think you're pessimistic, it's like taking your umbrella every time you go out regardless,

87
00:06:36,670 --> 00:06:37,810
‫that's pessimistic, right?

88
00:06:37,810 --> 00:06:39,250
‫Because you think it's going to rain.

89
00:06:40,420 --> 00:06:42,040
‫Don't get me wrong, I love rain.

90
00:06:42,040 --> 00:06:48,540
‫But if you don't like rain and you think it's going to rain, you're always going to take the umbrella

91
00:06:48,550 --> 00:06:48,910
‫of you.

92
00:06:50,160 --> 00:06:54,660
‫I'm talking when you leave the car, not in the car, of course, you can have it in the car there,

93
00:06:54,810 --> 00:06:59,070
‫but even if you go to the grocery store, you can go for a walk.

94
00:06:59,070 --> 00:07:00,600
‫You take the umbrella with you all the time.

95
00:07:00,720 --> 00:07:01,770
‫That's pessimistic.

96
00:07:02,030 --> 00:07:03,980
‫Concurrency control, right?

97
00:07:05,380 --> 00:07:10,180
‫If it rained, you have a rare right, you might say, and what's wrong with is that it seems like this

98
00:07:10,180 --> 00:07:12,010
‫is the best approach ever.

99
00:07:12,040 --> 00:07:13,290
‫Always take the umbrella with you.

100
00:07:13,660 --> 00:07:20,290
‫The umbrella is heavy, the umbrella cost, strength ride.

101
00:07:20,500 --> 00:07:24,940
‫My skinny arm cannot handle them, but I love locks all the same way.

102
00:07:25,150 --> 00:07:26,530
‫Locks are expensive.

103
00:07:26,680 --> 00:07:28,900
‫Locks need management.

104
00:07:28,900 --> 00:07:31,600
‫You need to manage locks that are free.

105
00:07:31,930 --> 00:07:33,310
‫Living locks are free.

106
00:07:33,610 --> 00:07:34,540
‫They are not.

107
00:07:34,930 --> 00:07:37,180
‫Nothing in this world is free.

108
00:07:37,690 --> 00:07:43,180
‫You've got to understand that everything is a program and everything needs to be coded and locks need

109
00:07:43,180 --> 00:07:43,750
‫to be coded.

110
00:07:43,750 --> 00:07:46,780
‫And they are so -- expensive.

111
00:07:46,960 --> 00:07:50,800
‫They are so God dang hard to get right.

112
00:07:52,810 --> 00:07:57,730
‫And now you can get to this like, oh, that is the ideal Frole level log's.

113
00:07:58,040 --> 00:08:00,310
‫There is an ideal table log's.

114
00:08:00,520 --> 00:08:03,060
‫There is that ideal page log's.

115
00:08:03,370 --> 00:08:03,650
‫Right.

116
00:08:03,850 --> 00:08:07,990
‫And you can define what all these mean a table look.

117
00:08:07,990 --> 00:08:13,010
‫I mean, hey, don't don't allow anyone to touch this or table or look.

118
00:08:13,090 --> 00:08:15,580
‫I mean, don't allow anyone to update this.

119
00:08:15,850 --> 00:08:17,440
‫Now, I'm going to ask you this question.

120
00:08:17,740 --> 00:08:19,900
‫How would you implement rollover level locks?

121
00:08:21,360 --> 00:08:29,970
‫Could be another table, right, some some simple example, keep in memory a running and running ledger

122
00:08:29,970 --> 00:08:32,610
‫of all the rows that have been locks.

123
00:08:34,290 --> 00:08:36,960
‫Some of you might say that's dumb.

124
00:08:38,230 --> 00:08:38,710
‫Why?

125
00:08:39,310 --> 00:08:50,080
‫Because what if a transaction updater million ro your memory is going to need to manage a million wrong?

126
00:08:51,670 --> 00:08:52,300
‫Oh yeah.

127
00:08:52,900 --> 00:08:53,530
‫Oh yeah.

128
00:08:54,430 --> 00:08:55,950
‫Well you have to have a million.

129
00:08:56,380 --> 00:08:58,800
‫Our memory is memory free.

130
00:08:59,230 --> 00:09:02,410
‫No, memory is not free.

131
00:09:03,070 --> 00:09:05,650
‫My friend's memory is not free.

132
00:09:05,650 --> 00:09:10,130
‫So lock management is expensive.

133
00:09:10,480 --> 00:09:13,270
‫That's French, by the way, for expensive if you didn't get it.

134
00:09:14,990 --> 00:09:17,690
‫Lock management is expensive, especially euro level locks.

135
00:09:17,710 --> 00:09:21,190
‫That's why most databases try not to implement rollover locks.

136
00:09:23,440 --> 00:09:31,810
‫And we can get into this role management and dive deep into how each database manage locks.

137
00:09:31,810 --> 00:09:34,140
‫And that's how you pick a database.

138
00:09:34,150 --> 00:09:40,210
‫By the way, guys, it's not because what is faster once it really depends on on you and what do you

139
00:09:40,210 --> 00:09:40,360
‫need?

140
00:09:40,360 --> 00:09:42,880
‫I still didn't come to the other.

141
00:09:43,210 --> 00:09:46,090
‫This is what talk is, still pessimistic or pessimistic.

142
00:09:46,620 --> 00:09:48,170
‫And I say good luck management.

143
00:09:48,210 --> 00:09:49,570
‫So difficult.

144
00:09:49,870 --> 00:09:51,400
‫Difficult, right.

145
00:09:53,080 --> 00:10:00,450
‫And then so so some some databases like SQL Server, for example, they manage locks in memory that

146
00:10:01,000 --> 00:10:03,670
‫the more put raw locks in memory.

147
00:10:03,850 --> 00:10:08,890
‫You're going to blow up your memory very quickly so you can.

148
00:10:09,820 --> 00:10:17,310
‫So SQL Server have this idea of something called lock escalation where says, OK, I'm about to lock

149
00:10:17,590 --> 00:10:19,270
‫seven thousand rows.

150
00:10:19,690 --> 00:10:20,350
‫You know what?

151
00:10:20,560 --> 00:10:24,940
‫If you're touching this many rows, I don't trust you.

152
00:10:25,630 --> 00:10:31,060
‫I'm going to save memory and I'm going to lock I'm going to put one lock on the entire table.

153
00:10:33,310 --> 00:10:33,990
‫Yikes.

154
00:10:34,480 --> 00:10:36,430
‫Yes, you just lucky that timetable.

155
00:10:37,860 --> 00:10:43,260
‫Right, which is which is sometimes it is memory efficient.

156
00:10:44,250 --> 00:10:51,000
‫But you cause more weight on other transactions and those transactions are low running that up the toll

157
00:10:51,000 --> 00:10:53,350
‫roads, you are doomed.

158
00:10:53,400 --> 00:10:54,420
‫My friends, you're.

159
00:10:54,990 --> 00:10:56,690
‫So as it goes over, you can tune this.

160
00:10:56,700 --> 00:10:59,040
‫That's where database tuning comes in.

161
00:10:59,070 --> 00:11:05,010
‫Other databases, which is my favorite PostgreSQL manage rows, row locks.

162
00:11:06,370 --> 00:11:12,940
‫In desk, and you might say that that's just dumb, because it that that I have to write a desk to lock

163
00:11:12,940 --> 00:11:13,480
‫the table.

164
00:11:14,700 --> 00:11:20,990
‫Well, if you think about it, if you were right to a role, aren't you writing to ask anyway?

165
00:11:21,270 --> 00:11:22,860
‫How about we just lock in there?

166
00:11:23,130 --> 00:11:27,780
‫OK, so they are they are smarter than I have time to explain the details of that.

167
00:11:27,780 --> 00:11:30,260
‫I don't even get the level of details.

168
00:11:30,270 --> 00:11:32,660
‫They are these in hints.

169
00:11:32,730 --> 00:11:34,250
‫They they manage all this stuff.

170
00:11:34,500 --> 00:11:35,460
‫This is what interested me.

171
00:11:35,580 --> 00:11:37,830
‫The I love this stuff.

172
00:11:38,220 --> 00:11:45,240
‫I love to talk about these different decisions that engineers make based on like if you go this way,

173
00:11:45,240 --> 00:11:45,810
‫you go this way.

174
00:11:45,810 --> 00:11:47,960
‫If you go this way, then it goes right.

175
00:11:48,300 --> 00:11:49,770
‫You you can build completed.

176
00:11:49,980 --> 00:11:55,590
‫That's where databases go completely different path based in the simple decision that they make a branch

177
00:11:55,590 --> 00:11:56,150
‫decision.

178
00:11:56,640 --> 00:12:00,990
‫So Postgres don't put the law because of memory, but they do it on desk.

179
00:12:00,990 --> 00:12:08,910
‫So that means they have more IO SQL Server on the other hand, put it on memory, but you have like

180
00:12:08,920 --> 00:12:10,430
‫escalation and all that stuff.

181
00:12:10,920 --> 00:12:19,770
‫Let's stop talking about pessimistic gun control and let's go to the lock free optimistic ocasek.

182
00:12:19,800 --> 00:12:22,950
‫And we are optimistic people.

183
00:12:23,730 --> 00:12:26,430
‫We are open minded.

184
00:12:27,540 --> 00:12:33,240
‫We like life and we are pro humanity.

185
00:12:33,330 --> 00:12:33,840
‫I don't know.

186
00:12:33,840 --> 00:12:42,840
‫I'm saying we are so optimistic that we say, sir, you can update this field, you can update this

187
00:12:42,840 --> 00:12:44,940
‫role, and we're not going to unlock it.

188
00:12:45,540 --> 00:12:46,080
‫Why?

189
00:12:46,440 --> 00:12:53,160
‫Because chances that some other transactions are going to be updated are really low.

190
00:12:53,880 --> 00:12:54,750
‫Let's be blips.

191
00:12:56,520 --> 00:12:58,170
‫Let's be optimistic a little bit.

192
00:12:58,530 --> 00:13:02,850
‫Don't take that -- umbrella with you if it rain well.

193
00:13:04,160 --> 00:13:08,870
‫You can just go to the store and buy one or just throw out, OK, OK, you get a little bit wet, who

194
00:13:08,870 --> 00:13:09,500
‫cares?

195
00:13:11,230 --> 00:13:14,020
‫So that's optimistic because the control.

196
00:13:14,680 --> 00:13:15,560
‫So what does that mean?

197
00:13:16,060 --> 00:13:22,680
‫That means if you update a rule, just do your own thing and then commit.

198
00:13:24,010 --> 00:13:30,900
‫But during the commit, we're going to do a slight Beeny check at the committee level.

199
00:13:31,660 --> 00:13:39,790
‫We're going to say if the rule change underneath you, we're going to fail your transaction.

200
00:13:41,710 --> 00:13:45,340
‫Some of you might cringe at that, I understand.

201
00:13:46,380 --> 00:13:52,260
‫But hey, just try it, you got to go get go change your clothes, son.

202
00:13:52,530 --> 00:13:53,650
‫It's OK.

203
00:13:54,150 --> 00:13:55,120
‫Who cares?

204
00:13:55,140 --> 00:13:56,720
‫It's just little water.

205
00:13:57,000 --> 00:13:58,280
‫It's a little bit of water.

206
00:13:58,290 --> 00:14:06,900
‫So if it fails, just roll back, fail, give the user a little bit of a beautiful error that says,

207
00:14:07,260 --> 00:14:09,030
‫OK, just chill.

208
00:14:09,510 --> 00:14:10,560
‫It's not a big deal.

209
00:14:11,490 --> 00:14:18,300
‫And Mongo DB, as is this model uses this thing that's called Wire Tiger and that I'm researching more

210
00:14:18,300 --> 00:14:27,180
‫about why Target is exclusively it looks like it's an exclusively lugg structure military and designed

211
00:14:27,180 --> 00:14:35,490
‫around the idea of having it uses multicore uses, tries to suck the life out of your SEIP multiple

212
00:14:35,490 --> 00:14:40,290
‫core CPU as much as possible, try to utilize them to the to the maximum efficiency.

213
00:14:41,010 --> 00:14:42,540
‫And that's what they claim.

214
00:14:42,570 --> 00:14:43,620
‫I'm just reading.

215
00:14:43,620 --> 00:14:43,910
‫Right.

216
00:14:44,250 --> 00:14:48,810
‫And the most important part is they use optimistic concurrency control.

217
00:14:49,320 --> 00:14:50,460
‫They say, well.

218
00:14:51,700 --> 00:14:55,010
‫I don't want to deal with the headache of managing my locks.

219
00:14:55,240 --> 00:14:58,930
‫I don't want to take my umbrella with me everywhere I go.

220
00:14:59,200 --> 00:15:00,580
‫Ambarella Zahavi.

221
00:15:02,010 --> 00:15:10,140
‫Stop taking your umbrellas with you and instead just be optimistic, my friend, be optimistic.

222
00:15:10,200 --> 00:15:11,680
‫Why are you like this?

223
00:15:12,600 --> 00:15:13,170
‫Why?

224
00:15:15,110 --> 00:15:24,950
‫It's OK if it fails to try your transaction, so now you put some more burden on the client side to

225
00:15:24,950 --> 00:15:26,240
‫retry the transactions.

226
00:15:27,160 --> 00:15:33,850
‫And most developers might be familiar with this model says, OK, yeah, I know I get this very all

227
00:15:33,850 --> 00:15:37,630
‫the time, just really trying, which is doesn't sound like a big deal.

228
00:15:37,660 --> 00:15:40,900
‫Yeah, a little bit of code at your end.

229
00:15:41,960 --> 00:15:45,510
‫And to be honest, I don't I don't have a favorite.

230
00:15:45,520 --> 00:15:52,900
‫I just think every use case really depends on on how which path to take.

231
00:15:52,930 --> 00:15:56,500
‫You want to take the optimistic path or you want to take the pessimistic path.

232
00:15:57,010 --> 00:15:57,310
‫Right.

233
00:15:57,880 --> 00:16:01,780
‫Usually usually databases don't call themselves pessimistic.

234
00:16:02,230 --> 00:16:07,810
‫You're not going to go to Bosco's and you can read their book is all we're using pessimistic anti-gun

235
00:16:07,960 --> 00:16:08,360
‫control.

236
00:16:08,410 --> 00:16:12,770
‫No, no, nobody's saying that because that's kind of a negative way, right?

237
00:16:12,890 --> 00:16:13,810
‫Nobody writes that.

238
00:16:14,080 --> 00:16:20,920
‫But you are going to see mongerer talk about all this optimistic as it gets, because optimistic is

239
00:16:20,920 --> 00:16:22,210
‫way better than pessimistic.

240
00:16:22,220 --> 00:16:22,470
‫Right.

241
00:16:23,260 --> 00:16:31,030
‫But technically speaking, Postgres, MySQL, SQL Server, Oracle, even, they are pessimistic.

242
00:16:31,300 --> 00:16:35,920
‫This is GANDIL locks on and we're going to lock this stuff.

243
00:16:36,310 --> 00:16:36,690
‫All right.

244
00:16:37,240 --> 00:16:39,550
‫Obviously, I might have missed some of the things.

245
00:16:39,790 --> 00:16:43,600
‫What do you think is best in your personal opinion?

246
00:16:43,750 --> 00:16:46,330
‫Let's just have a discussion and have a discussion.

247
00:16:46,330 --> 00:16:47,410
‫What what do you think is.

248
00:16:47,410 --> 00:16:49,890
‫But I don't think there is a better way, to be honest.

249
00:16:49,900 --> 00:16:54,760
‫It's like I kind of prefer pessimistic because it's OK.

250
00:16:55,120 --> 00:16:56,200
‫I'm a pessimistic guy.

251
00:16:56,980 --> 00:16:58,180
‫It's like luck, my stuff.

252
00:16:58,180 --> 00:16:58,750
‫Don't touch it.

253
00:16:58,960 --> 00:16:59,890
‫Don't touch my stuff.

254
00:17:00,580 --> 00:17:01,630
‫Don't touch meyerrose.

255
00:17:02,610 --> 00:17:06,110
‫As long, but but also I think of all of these management of the locks, right?

256
00:17:06,570 --> 00:17:08,810
‫That's why I prefer Posterous, right?

257
00:17:08,920 --> 00:17:16,590
‫Yeah, you can see the right amplification results of postscripts because of all this managing the logs

258
00:17:16,590 --> 00:17:22,040
‫and the rights and all that stuff becomes a little bit too much sometimes.

259
00:17:22,800 --> 00:17:27,530
‫But if it's a cost you have to pay compared to memory, you might say, hey, I'm going to use SQL Server,

260
00:17:28,050 --> 00:17:30,270
‫I'm going to put all my lacson on memory.

261
00:17:30,480 --> 00:17:33,100
‫I'm going to have to terabytes Wolfram.

262
00:17:33,120 --> 00:17:35,910
‫All right, guys, I'm going to see in the next one you guys, the awesome by.