Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of enis.soz@gmail.com designates
 209.85.160.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1400891279.11418.YahooMailNeo@web140603.mail.bf1.yahoo.com>
References: <1400891279.11418.YahooMailNeo@web140603.mail.bf1.yahoo.com>
From: =?UTF-8?Q?Enis_S=C3=B6ztutar?= <enis.soz@gmail.com>
Date: Fri, 23 May 2014 17:54:27 -0700
Message-ID: 
 <CAMUu0w-7quGnhwzRSQQ4-HA1hrjLZ_9_RZTyFBDdy9C=Tej72w@mail.gmail.com>
Subject: Re: Timestamp resolution
To: "dev@hbase.apache.org" <dev@hbase.apache.org>,
 lars hofhansl <larsh@apache.org>
Content-Type: multipart/alternative; boundary=001a1133db94f5ac5104fa1aca41

--001a1133db94f5ac5104fa1aca41
Content-Type: text/plain; charset=UTF-8

+1 to micros. We should do it at the table level rather than CF level?

How can we get the micros resolution efficiently in java?

Enis


On Fri, May 23, 2014 at 5:27 PM, lars hofhansl <larsh@apache.org> wrote:

> We have discussed this in the past. It just came up again during an
> internal discussion.
> Currently we simply store a Java timestamp (millisec since epoch), i.e. we
> have ms resolution.
>
> We do have 8 bytes for the TS, though. Not enough to store nanosecs (that
> would only cover 2^63/10^9/3600/24/365.24 = 292.279 years), but enough for
> microseconds (292279 years).
> Should we just store he TS is microseconds? We could do that right now
> (and just keep the ms resolution for now - i.e. the us part would always be
> 0 for now).
> Existing data must be in ms of course, so we'd grandfather that in, but
> new tables could store by default in us.
>
> We'd need to make this configurable both the column family level and
> client level, so clients could still opt to see data in ms.
>
> Comments? Too much to bite off?
>
> -- Lars
>
>

--001a1133db94f5ac5104fa1aca41--