Ah, okay. Thanks for the pointer to PHOENIX-1178. Do you think the stats table is the right place for this kind of info? Seems like the only choice. Is there a plan to make the stats table a stable internal API? For instance, integration with Kylin for building Cubes off of denormalized event tables in Phoenix, or supporting BlinkDB approximation queries could both be facilitated by the stats table.
-n On Thu, Apr 14, 2016 at 12:24 PM, James Taylor <[email protected]> wrote: > FYI, Lars H. is looking at PHOENIX-258 for improving performance of > DISTINCT. We don't yet keep any cardinality info in our stats > (see PHOENIX-1178). > > Thanks, > James > > On Thu, Apr 14, 2016 at 11:22 AM, Nick Dimiduk <[email protected]> wrote: > >> Hello, >> >> I'm curious if there are any tricks for estimating the cardinality of the >> values in a phoenix column. Even for leading rowkey column, a select >> distinct query on a large table requires a full scan (PHOENIX-258). Maybe >> one could reach into the stats table and derive some knowledge? How much of >> a "bad thing" would this be? >> >> Thanks, >> Nick >> > >
