You mean a 2 phase fetch? So every time a page is requested, an array of comment ids for the page is resolved from memcache or database (phase 1) and then there is an additional multiget() for an array of comment ids (and possible another query with IN() is issued for the ones that are missing, Phase 2) is made, and text for comments is returned. Sure, that works.
On Tue, Sep 16, 2008 at 4:23 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote: > > On Tue, 16 Sep 2008, Boris Partensky wrote: > > Pages will shift as new items get inserted on top, so they all need to be >> invalidated. Am I wrong? >> I wouldn't try and do anything tricky unless you absolutely have to. If >> query needs to be re-run every 10 min, >> I don't see why bother. I would store multiple pages in cache, but that's >> just so you don't have to paginate in memory upon every request. >> > > Even if your total result set is reasonably large, if you just store the > "post IDs" or whatever you can cache the entire set as a single key. 1000 > 32-bit IDs is still only 4KB. I doubt you can even show a speed difference > between fetching a 4KB cache value and a 40 byte cache value. > > If you just have an array of post IDs, doing the pagination in the app > server is also unlikely to take any serious amount of time - just a few > microseconds to slice out of the 4KB array. > > I wouldn't advocate this for result sets with thousands and thousands of > elements, but we use it successfully for sets like "Fans of an Artist" or > "Friends of a user" which usually are very small and only occasionally go > into the several hundreds or thousands range. > > -Todd > -- --Boris
