phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <>
Subject Re: Recreating SYSTEM.CATALOG metadata
Date Mon, 29 Sep 2014 00:54:26 GMT
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,

-- Lars

----- Original Message -----
From: James Taylor <>
To: user <>
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.

On Sun, Sep 28, 2014 at 1:56 PM, Krishna <> 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

View raw message