Hi David, a) Recently we tested huge concurrent load and compactions but never faced two loads using same segment id issue (because of table status lock in recordNewLoadMetadata), so I am not sure whether we really need to update to UUID.
b) And about other segment interfaces, we have to refactor it. It is long pending. Refactor such that we can support TIME TRAVEL. I have to analyze more on this. If somebody has already done some analysis can use thread to refactor the segment interface discussion. Thanks, Ajantha On Fri, Sep 4, 2020 at 1:11 PM Kunal Kapoor <kunalkapoor...@gmail.com> wrote: > Hi David, > Then better we keep a mapping for the segment UUID to virtual segment > number in the table status file as well, > Any API through which the user can get the segment details should return > the virtual segment id instead of the UUID. > > On Fri, Sep 4, 2020 at 12:59 PM David CaiQiang <david.c...@gmail.com> > wrote: > > > Hi Kunal, > > > > 1. The user uses SQL API or other interfaces. This UUID is a > transaction > > id, and we already stored the timestamp and other informations in the > > segment metadata. > > This transaction id can be used in the loading/compaction/update > > operation. We can append this id into the log if needed. > > Git commit id also uses UUID, so we can consider to use it. What > > information do you want to get from the folder name? > > > > 2. It is easy to fix the show segment command's issue. Maybe we can > sort > > segment by timestamp and UUID to generate the index id. The user can > > continue to use it in other commands. > > > > > > > > ----- > > Best Regards > > David Cai > > -- > > Sent from: > > http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/ > > >
