MSet::fetch() hint ignored by remote backend

[Richard Boulton]

The old "network" backend (removed in r7141) implemented specialised request_document() and collect_document() methods. These were used to allow the MSet::fetch() methods to request the documents which the user wanted in bulk, rather than having a request-fetch conversation across the link for each document.

The new "remote" backend, since it was implemented in r7141, doesn't have this specialisation. I believe it should be added back, so that it's possible to get the full contents of matches in bulk. However, if it isn't to be added back in, we should remove the machinery in Xapian::MSet and Xapian::Database::Internal which is there to support this feature.

[Olly Betts]

I didn't reimplement them as my testing (of the old remote backend) didn't show any speed up. I thought there was a comment somewhere about this but I don't see it.

I wondered if it might make a difference with higher latency connections, or other circumstances than those I tested (or if something about the old protocol was perhaps the problem) so I didn't strip out the API at the time.

This certainly merits further study though.

If we want to keep this, the current API seems sane so this could be done at any point. If we want to strip out the remaining machinery and deprecate MSet::fetch(), then in or before 1.2.0 would be best. So I think 1.2.0 is the appropriate milestone unless you're planning to work on this urgently.

[Richard Boulton]

No, but I'm likely to be doing at least one of several potential projects using the remote backend heavily in the next 6 months, so might get a good chance to benchmark this in real-world situations. Don't really mind what the milestone is, as long as there's a ticket for me to refer to. :)

[Olly Betts]

This isn't 1.2.x material now.

[Olly Betts]

We should decide (probably by profiling) if we're going to keep this feature or not.

If we are, it should actually be implemented; if not, we should remove the machinery, deprecated the methods, and make them inline no-ops or compatibility wrappers in the API headers.

[Olly Betts]

It seems that fetch() may be useful for local databases, as we can give the OS hints to prefetch blocks from the record table to speed up getting results. See #671.

So bumping this until we have more idea about that.

[Olly Betts]

I think we keep this API. Leaving this open to review whether we can actually make use of it for the remote backend.

[Olly Betts]

It occurs to me that if we don't reimplement fetching documents across the link in response to MSet::fetch() for a remote database, then it should probably at least cause us to perform "local" prefetch but on the server, to help ensure the data needed to service get_document() is in the disk cache there so the server responds more quickly.

[Olly Betts]

It'd be good to implement the local-prefetch-on-remote for 1.5.0 as it'll require a protocol addition (could be done as a minor protocol bump, but cleaner to do with the start of a new release series).

I'll see if I can get it done, but might still postpone this.

[Olly Betts]

Implemented sending the prefetch request to get run on the remote server in git master in 02bfcf0541c6beacf25501d95f759baf485b058b. We could probably backport to 1.4.x with a remote protocol minor version bump but I'm not currently planning to as minor bumps are still a slightly less smooth experience for users upgrading, and we're a long way into 1.4.x now (also I want to focus on actually getting the next release series out).

I'm going to close this ticket now. I've opened #827 for investigating whether it's worth implementing something like what MSet::fetch() did in the old "network" backend, i.e. trigger documents to actually get fetched from the remote in the background.