||[Jun. 26th, 2005|09:07 pm]
A linear search of my entire journal text isn't too slow with InnoDB. In fact it's pretty damn fast.
Props to InnoDB and how our indexes are setup to cluster all rows based on primary key of form (journalid, jitemid)... so an entire journal is next to each other in the b-trees/disk.
People/things I've mentioned a lot:
(you can tell I use LJ a lot less than during college, eh?)
And <lj user=...> I do a lot:
You should have <lj user="">'d all of those in the last list.
Addendum: and instead of using numbers, just use each the requisite number of times.
Bonus points: count the then-current version of the post against it, etc.
I should really just get drunk, then this will make sense.
Next to each other when it's been optimized, yeah? I wonder how it handles sequential reads in that case.
...and damn, you linked alanj more than me!? ;) He did write more code, I think. Man, it feels like some people are missing from that list, did you edit it? Must've been non-tags (pre-lj user tag, even?).
Wow, that sounds retarded. I kept editing the comment while Lore was showing me a drawing :P
2005-06-27 05:33 am (UTC)
dina lost out to perl...burn!
oooh, somebody's sleeping on the couch...
Makes me wonder whether pulling more old entries from a journal at once, instead of switching to day at a time mode, might be practical. Assuming that too many seeks with MyISAM was the reason for switching.
2005-06-27 06:52 am (UTC)
What are you talking about? The back-back-back-back links eventually going to day mode? I want it that way --- ?skip=8503 is a terrible URL to have cached and linked, being so unstable.
Yes, that back thing. Not so good for caching but the switch to day at a time mode usually also means switching from worth reading to too much hassle to be worthwhile, usually.
Agreed. If you're gonna read backwards, it stops being worth it at that point.
Brad has a good point about caching though. Should switch to by month or perhaps by week rather than using increasing offsets.