I know ICE looks like it going after the BI market but with its column based storage and compression it looks perfect for archival storage too. I would like to see support for longtext and longblob types which are essential for massive XML columns that seem to be cropping up all over the place these days. (Not sure how to get the blobs loaded at this point but longtext would be start)
Not sure the query has to work too hard on the details of these columns but being able to return a good chunk based other columns search criteria would do. Normally I would just throw it in an myISAM table and use the compress/uncompress as required as the compression capability of XML is high and could save a fortune on spiny brown stuff, but to have the compression done seamlessly in the background by the BH engine greatly simplifies everything and would reduce application complexity enormously.

Hello Ken,

I know ICE looks like it going after the BI market but with its column based storage and compression it looks perfect for archival storage too. I would like to see support for longtext and longblob types which are essential for massive XML columns that seem to be cropping up all over the place these days.

You’re not first person to want/use Infobright for purely archival purposes, and we are looking at better ways to support that. In the past we’ve shied away from data types that we know we can’t optimize from a query perspective - but as you point out in a purely archival use case, you’re not looking for query speed, you’re after the automated and deep compression.

Let me look into the work here. We don’t support blob in any shape so that will be more problematic. We do support TEXT (up to 65K), so I’ll check first on expanding TEXT support for LONGTEXT (up to 4GB).

Kind regards,
Andrew

Does infobright not have support for DECIMAL datatype?  I tried to create a table with DECIMALS in it, and I got an error message stating that there was an unsupported datatype in the create statement (but not WHICH datatype was unsupported).  So, I tried a test table:

create table foo (money decimal(19,3));

and got the following error message:

ERROR 8 (HY000): Unsupported data type

I can work around this by storing my decimals as bigints and scaling them when I pull them out of the database, but this seems like a pretty obvious thing to support in a data warehouse environment. 

Also, I could not find any reference in the documentation that’s available to me about which datatypes are/aren’t supported (I could have missed it).

Nevermind, I found my own answer (in the docs that I couldn’t find before):

Infobright support DEC, but not DECIMAL. 

When I exported the DDL from my current MyISAM implementation, it exported the column types as DECIMAL which the Infobright engine would not use.  I’ll change them to DEC and they should work.

Hi,

You can also find out more information about supported datatypes on the wiki.

Regards,
Mark

For those who don’t have easy access to the documentation, INFOBRIGHT supports DEC/DECIMAL(18,x) as described below:

Ahh..  That’s the trouble…  We had DECIMAL(19,x) in our database…  So it was just the size that was the problem.

Sooooooooo close!

Hello,

But would you be generally okay to use decimal(18,3) instead of decimal(19,3) in this case?

Best greetings,

Dominik