So what's the final status on this patch ? 2009/2/23 Jean-Charles Redoutey <[email protected]>
> this looks like a pretty efficient summary of the whole thread ! > > To come back on Dormando's point: any global consistency issue can be > solved by full flush, so I can't honestly say it is an absolutely necessary > feature. However, by dramatically reducing the DB cost of such flush > operations, (you can't save resources as this is still needed for > reliabitily, ok) but you don't have to think twice (or argument 2 hours with > your DBA) anymore and thus you can do it when you fonctionally want, which > ultimate result is to give a significant higher quality to the data hosted > in the cache, and this is probably worth 10 lines of code ;-) > > To make a bad comparison, it's like ABS brakes: a very good driver can be > more efficient, you can still break without it ... but with it, the whole > road network is safer ! > > Back to your post, Dustin, could you detail what you mean by "generational > prefix mechanism", or give a pointer? I think I almost figure out the idea, > but not the whole details and google didn't find much about prefix in the > mailing list for me... > --- > Jean-Charles > > > > On Mon, Feb 23, 2009 at 20:31, Dustin <[email protected]> wrote: > >> >> >> On Feb 22, 5:02 pm, dormando <[email protected]> wrote: >> >> > It feels excessive if the only real benefit is being able to do a full >> > data flush in less time? Is there anything I'm missing? >> >> This is kind of how I see it: >> >> Pros: >> >> * It's consistent with flush_all [n] for positive values of n if you >> consider flush_all to mean "remove items older than n" >> * The patch is really small and simple. >> * This is functionality that can't be performed (exactly) on the >> client side (would've been a good argument against flush_all n). >> >> Cons: >> >> * It's inconsistent with flush_all if you think of flush_all as >> "remove all objects" >> * Item structure overhead is increased. >> * Generally raises the "this will be abused" flag >> >> >> As far as not being possible to do without the server change (pro >> #3), this can be done with a generational prefix mechanism, which I'd >> expect to be preferable as it would be more exact than time. >> >> >
