That seems like a good option to have to me in any case. As long as one knows what one is doing... For example somebody might want to map-reduce the extra column in, or issue an HBase bulk load just for this column. There might be more things. It'd allow to bridge the gap between existing data and Phoenix a bit better.
Also one could fat finger the SYSTEM.CATALOG table, and as long as one knows the DDL one could cheaply restore it without actually touching the data. I'd go even further and say that _anywhere_ Phoenix needs to touch every row for an operation there should be an option to avoid that - with the caveat that you better know what you're doing. Might even be a special connection mode only, or something. Agree with James that in this case it'd be best to include the SYSTEM.CATALOG in the backup, though. -- Lars ----- Original Message ----- From: James Taylor <jamestay...@apache.org> To: user <user@phoenix.apache.org> Cc: Sent: Sunday, September 28, 2014 5:09 PM Subject: Re: Recreating SYSTEM.CATALOG metadata Hi Krishna, Any reason why the SYSTEM.CATALOG hbase table isn't restored as well from backup? Yes, if you try to re-create the SYSTEM.CATALOG by re-issuing your DDL statement, Phoenix won't know that the tables were Phoenix tables before, so will try to add the empty key value to each row. It's possible that an option could be made to avoid this, but it'd be good to understand a bit more why this is needed. Thanks, James On Sun, Sep 28, 2014 at 1:56 PM, Krishna <research...@gmail.com> wrote: > Hi, > > When I restore hbase from a backup, sqlline gets stuck unless SYSTEM.CATALOG > table is dropped. It is automatically re-created via sqlline. However, > metadata of previously created phoenix tables is lost. > > So, to restore the metadata, when a 'CREATE TABLE' statement is re-issued, > Phoenix takes very, very long time to execute which I think, is because > Phoenix is upserting null value for _0 column qualifier again for every row > (billions of rows in the table). > > Is there a work-around for this by somehow telling Phoenix that the > underlying table is already a Phoenix table? Using views is not an option > here. If my understanding is wrong, any pointers as to why it takes so long > for executing 'CREATE TABLE' statement is appreciated. > > Thanks > >
