Claudio Martella 2011-06-18, 16:00
Andrew Purtell 2011-06-18, 19:24
Claudio Martella 2011-06-20, 12:58
Andrew Purtell 2011-06-20, 15:14
Joey Echeverria 2011-06-20, 15:23
Ted Yu 2011-06-20, 15:36
Ted Dunning 2011-06-20, 15:50
Joe Pallas 2011-06-20, 17:27
Ah, I didn't realize that increment returns the value. Yes, the
current behavior is required in that case. I was thinking of a use
case more like the one Ted described, where you're keeping metrics,
but don't read the values that frequently. Maybe this should be a new
If no one objects, I'll file a JIRA.
On Mon, Jun 20, 2011 at 1:27 PM, Joe Pallas <[EMAIL PROTECTED]> wrote:
> On Jun 20, 2011, at 8:50 AM, Ted Dunning wrote:
>> Lazy increment on read causes the read to be expensive. That might be a win
>> if the work load has lots of data that is never read.
>> This could be a good idea on average because my impression is that increment
>> is usually used for metric sorts of data which are often only read in detail
>> in diagnostic post mortem use cases.
> Just so we're clear, we'd be talking about a new operation, right? Because today's increment returns the incremented value, and some uses (like generating unique values) do require that.
Jeff Whiting 2011-06-20, 18:28