[LU-15516] Simplify mmap readahead logic & remove clustered reads

• Type: Improvement
• Resolution: Unresolved
• Priority: Minor
• Assignee: Patrick Farrell (Inactive)
• Reporter: Patrick Farrell (Inactive)

Description

The addition of clustered reads created a huge amount of mmap specific readahead logic, most of which doesn't work well.  mmap readahead should not be a separate consideration from regular readahead logic.

The clustered readahead code is particularly problematic:

Here's what the clustered code actually does.

It does 'blobs' of reading around the point of a read.
Ideally, we'd do this when we couldn't detect a pattern, but the clustered reads code just does this, effectively disabling normal readahead for mmap.

This means if there isn't any pattern, it can speed things up a lot

But if there's any pattern, this is worse than following it.  And there is almost always a pattern.

It's based on a weird idea about 'clustered reads', but there's zero reason to think those exist - databases don't work like that and there's no justification offered.
Databases do sequential forward, sequential back, semi-random forward, semi-random back, and full random.  There's no clustered behavior as described, ie, 'read randomly in an area for a bit then move to another area'.

It makes sense, when we can't detect a pattern, to consider this 'just read some pages' approach, since reading a few more pages is a great idea in most cases.

But this is a separate thing and a very poor excuse for breaking mmap reads so badly.

It also shouldn't be separate logic - if this makes sense for mmap, it makes sense for regular reads.

LU-14917 tries to hack around this by creating an even more complicated logic path to keep this clustered reads.  We're better off removing them and considering adding them back in a future patch, when they can be used for both regular and mmap reads.

This LU will do that, and will also standardize/unify the readahead invocations for mmap reads and regular reads.