Hi Teradata colleagues!
I have to do some modifications in production:
1) Modify existing collumns
2) Add some new collumns
3) Drop and re-create primary index
Can anyone help me in 1) case - modifying column segment with addition of compress part:
segment CHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC COMPRESS ('AM ','CAM ','KAM ','KO ','PSHC ','RES ','SBS ')
How to add this column:
pot_klasse CHAR(1) CHARACTER SET LATIN NOT CASESPECIFIC COMPRESS ('B','U')
How to make new index? (Do I have to drop it first and then make a new one?)
NOTE: All of this information can be found in the Teradata Manuals available for download from here. From there you can select the release which you are interested in on the upper right of the screen.
Adding Value List Compression to Existing Column
Depending on the table size and duration which you can tolerate the table being exclusively locked you can add value list compression using ALTER TABLE. If there are sufficient presence bits in the table header for the compressed value list the operation can be fairly quick otherwise it will be fairly intensive:
ALTER TABLE MyDB.MyTable ADD SEGMENT CHAR(10)
COMPRESS ('AM', 'CAM', 'KAM', 'KO', 'PSHC', 'RES', 'SBS');
Otherwise you can create a new table with the value list compression defined on it, copy the statistics from the original production table to the new table, insert the data into the new table, and then rename the tables to introduce the new table as the production table.
Adding Column to Existing Table
If there are unused presence bits in the table header adding this column using ALTER TABLE can be a fairly quick operation. If there are not sufficient presence bits for the compressed value list to be captured ALTER TABLE would not be the recommended approach:
ALTER TABLE MyDB.MyTable ADD pot_klasse CHAR(1)
CHARACTER SET LATIN NOT CASESPECIFIC COMPRESS ('B','U');
Changing the Primary Index
It depends.
There are situations where you can modify the PI of the table without having to create a new table using ALTER TABLE. (e.g. non-unique to unique) However, more often than not you will find yourself having to create a new table and inserting the data from the original table to the new table. (e.g. Adding a column, changing the data type of a column in the primary index, etc.)
Related
I have a 3 GB SQLite database. I want to modify column type of one of the table columns.
I know that sqlite does not support altering columns and this can only be done by recreating a table.
That's how I do it:
BEGIN TRANSACTION;
ALTER TABLE tbl RENAME TO tbl_;
CREATE TABLE tbl (a INTEGER, b TEXT, c TEXT);
INSERT INTO tbl SELECT * FROM tbl_;
DROP TABLE tbl_;
COMMIT;
I thought that during this process since I use a transaction then the database size will not increase. But it did. On my disk not enough space to double the database size. Is it normal that the database size increases within the transaction? Is there any other way of modifying column type without increasing database size? This process also takes a lot of time. Unexpectedly, most of the time is taken by DROP TABLE statement, it's even longer than INSERT statement. Why dropping table is longer than copying data from one table to another?
Thanks in advance!
I want to add a column to an existing impala table(and view) with a default value (so that the existing rows also have a value). The column should not allow null values.
ALTER TABLE dbName.tblName ADD COLUMNS (id STRING NOT NULL '-1')
I went through the docs but could not find an example that specifically does this. How do I do this in Impala? Hue underlines/does not recognize the NOT NULL command
Are you using Kudu as a storage layer for your table? Because if not, then according to Impala docs,
Note: Impala only allows PRIMARY KEY clauses and NOT NULL constraints on
columns for Kudu tables. These constraints are enforced on the Kudu
side.
...
For non-Kudu tables, Impala allows any column to contain NULL values,
because it is not practical to enforce a "not null" constraint on HDFS
data files that could be prepared using external tools and ETL
processes.
Impala's ALTER TABLE syntax also does not support specifying default column values (in general, non-Kudu).
With Impala you could try as follow
add the column
ALTER TABLE dbName.tblName ADD COLUMNS(id STRING);
once you've added the column you can fill that column as below using the same table
INSERT OVERWRITE dbName.tblName SELECT col1,...,coln, '-1' FROM dbName.tblName;
where col1,...,coln are the previous columns before the add columns command and '-1' is to fill the new column.
I want to add an extra unique constraint to an existing table. This and other answers say it's not possible with sqlite, and suggest creating an unique index:
ALTER TABLE example ADD COLUMN new_unique TEXT;
CREATE UNIQUE INDEX new_unique_index ON example(new_unique);
This seems to work. However, I'm having trouble with UPSERTs:
INSERT INTO example (foo, old_unique, new_unique) VALUES ('foo', 'old', 'new') ON CONFLICT(old_unique, new_unique) DO UPDATE SET foo='foo';
This gives an error:
ON CONFLICT cause does not match any PRIMARY KEY or UNIQUE constraint
Is there any way I could adapt the ON CONFLICT clause of the statement above to work with the new "constraint"?
I tried using new_unique_index, to no avail. If it's impossible, is there any alternative to creating a new table with the new unique constraint and copying the values from the old table into the new one with NULL for the new constraint column? This would be burdensome. I imagine I could create a new table with all of the former's columns, except the old uniques, plus the new unique, and link them somehow, but it sounds messy and I have no idea how to proceed.
Minimum reproducible example:
CREATE TABLE example (foo TEXT, old_unique TEXT, UNIQUE(old_unique));
ALTER TABLE example ADD COLUMN new_unique TEXT;
CREATE UNIQUE INDEX new_unique_index ON example(new_unique);
INSERT INTO example (foo, old_unique, new_unique) VALUES ('foo', 'old', 'new') ON CONFLICT(old_unique, new_unique) DO UPDATE SET foo='foo';
Is there any way I could adapt the ON CONFLICT clause of the statement above to work with the new "constraint"?
(old_unique, new_unique) is a not a possible constraint target as there is no index that combines both columns, each is an individual constraint (so you could use one or the other, as my understanding is that you are limited to a single UPSERT clause and a single conflict target).
If instead of :-
CREATE UNIQUE INDEX new_unique_index ON example(new_unique);
You used
CREATE UNIQUE INDEX new_unique_index ON example(old_unique,new_unique);
Then the following will work :-
INSERT INTO example (foo,old_unique,new_unique) VALUES('foo','old','new') ON CONFLICT (old_unique,new_unique) DO UPDATE SET foo = 'foo';
(well at least not be rejected due to no covering primary key or index for the given conflict target).
If it's impossible, is there any alternative to creating a new table with the new unique constraint and copying the values from the old table into the new one with NULL for the new constraint column? This would be burdensome.
It's not really burdensome e.g. you could use :-
CREATE TABLE IF NOT EXISTS temp_example (foo, old_unique,new_unique, UNIQUE(old_unique,new_unique));
INSERT INTO temp_example SELECT *,null FROM example;
ALTER TABLE example RENAME TO old_example;
ALTER TABLE temp_example RENAME TO example;
DROP TABLE If EXISTS old_example;
i.e. as you are adding a column and it will be the last column then there is no need to code column names.
suppose we have a file with just one table named TableA and this table has just one column named Text;
let say we populate our TableA with 3,000,000 of strings like these(each line a record):
Many of our patients are incontinent.
Many of our patients are severely disturbed.
Many of our patients need help with dressing.
if I save the file at this level it'll be: ~326 MB
now let say we want to increase the speed of our queries and therefore we set our Text column as the PrimaryKey(or create index on it);
if I save the file at this level it'll be: ~700 MB
our query:
SELECT Text FROM "TableA" where Text like '% home %'
for the table without index: ~5.545s
for the indexed table: ~2.231s
As far as I know when we create index on a column or set a column to be our PrimaryKey then sqlite engine doesn't need to refer to table itself(if no other column was requested in query) and it uses the index for query and hence the speed of query execution increases;
My question is in the scenario above which we have just one column and set that column to be the PrimaryKey too, then why sqlite holds some kind of unnecessary data?(at least it seems unnecessary!)(in this case ~326 MB) why not just keeping the index\PrimaryKey data?
In SQLite, table rows are stored in the order of the internal rowid column.
Therefore, indexes must be stored separately.
In SQLite 3.8.2 or later, you can create a WITHOUT ROWID table which is stored in order of its primary key values.
How do I change the default value of an existing column in a table in sqlite3?
I have a table named notes with a boolean column named hidden. The default is set to true, I want to set it to false.
I don't think you can without replacing the whole table. From the fine manual:
SQL Features That SQLite Does Not Implement
Complete ALTER TABLE support
Only the RENAME TABLE and ADD COLUMN variants of the ALTER TABLE command are supported. Other kinds of ALTER TABLE operations such as DROP COLUMN, ALTER COLUMN, ADD CONSTRAINT, and so forth are omitted.
So there is no way to modify an existing column in SQLite. I think you'll have to create a new table with the appropriate default for hidden, copy all the data over, drop the original notes table, and then rename the new one.
SQLite stays lean by purposefully omitting a lot of features.
SQLite database browser allows you to drop columns, so you could drop the column with it, and then manually add the column with the default using the sqlite3 command line tool.
Create a new database with the same schema (but your new default value), attach both, and migrate.
For deleting columns or other changes that aren't supported by the "ALTER TABLE" syntax, I create a new table, migrate date into it, drop the old table, and rename the new table to the original name.
https://stackoverflow.com/a/998652/1020467
https://www.sqlite.org/lang_altertable.html