I have a code statement related with index creating
create index if not exists foo_table_index_any_id on paublic.foo_table (any_id);
Will the table be locked exclusively if the index has been already created there?
Related
i have a large query (Web Dashboard Query) with many temporary tables.i have created indexes on the temp table.the application that is using the query has a user management module with different levels of permissions.My question is are indexes created per session like the temp db ?
i don't want the indexes to be shared across sessions.
i have been doing something like
EXEC('CREATE INDEX idx_test'+ #sessionId + 'ON #TempTable (id1,id2)');
is this necessary. i have seen it done by some developers.
Indexes on temporary tables (#t, not ##t) are not shared across the sessions, and there is no need to invent a unique index name to an index on a temporary table.
What is different (and may be you have seen in the code from other developers) is CONSTRAINT NAME. Index name can be repeated many times for different tables, but a constraint name must be unique within the database.
So maybe you see the code for stored procedures that create a constraint name with reference to a session, this is an attempt to give a unique name to a constraint. Because if you launch a stored procedure that creates a temp table #t in two sessions, every session create it's own table with it's own name(not just #t, the system is adding additional symbols to a table name that makes it unique)
But if the same proc tries to create a CONSTRAINT PK_t, the first session will succeeded but the second will get an error that the constraint PK_t already exists in the database(tempdb)
I have a database with a lot of tables in it. Some of them have names which start with "mytable_". Those tables have some indexes. Now I need to move those indexes also to different server which has similar tables.
I would like to have a script which will create all those indexes that are in given tables on my local server.
Also I would like to make it this way that if this index is already created it will not crash.
How can it be done in Postgres (pg admin)
You can use pg_get_indexdef() to extra all the index definitions:
select replace(pg_get_indexdef(format('%I.%I', schemaname, indexname)::regclass), ' INDEX ', ' INDEX IF NOT EXISTS ')||';' as ddl
from pg_indexes
where schemaname = 'public'
and tablename like 'mytable\_%';
The replace is used to "inject" the IF NOT EXISTS so that the statement won't fail if such an index is already present in the target database.
Just spool the result of that query to a file.
I have a strange situation that I don't understand. I am running a block of SQL in a merge module to update a oracle schema. I am trying to change the primary key of several tables so I am performing the following steps:
Drop FK constraints,
Drop PK,
Drop PK Index (if the index persists after the PK is dropped),
Add new PK,
Add FK's
Here's my problem. All is well until we get to the part where indexes are dropped. The primary is dropped and (to the best of my knowledge) any index that Oracle created based on that key will drop instantly as well. I was having issues with the index persisting so I added the DROP INDEX script to be certain it is removed, however, this is what happens:
Alter Table TABLE1 Drop Constraint TABLE1_PK
The command ran successfully
DROP INDEX TABLE1_PK
ORA-01418: specified index does not exist (This is exactly what I expected)
ALTER TABLE TABLE1 ADD (CONSTRAINT TABLE1_PK PRIMARY KEY (TABLE_KEY) ENABLE VALIDATE)
ORA-00955: name is already used by an existing object (The object being, in each case, the old index)
This of course prevents any of the FK's from linking because they are now based on the new key. When I run this in TOAD, the SQL works, but I can't figure out why it doesn't through the merge module. Can anyone help?
I'm initializing a HSQL database 2.2.9 via Spring using
<jdbc:initialize-database enabled="true">
<jdbc:script execution="INIT" location="classpath:./create-tables.sql"/>
</jdbc:initialize-database>
In create-tables.sql I use
CREATE TABLE IF NOT EXISTS MyTable(...);
The table also has an index. I'm looking for a better way than always dropping and creating the index.
I tried:
CREATE INDEX IF NOT EXISTS myIndex ...;
does not work
I can create a function indexExisting() checking the system tables and returning count(*) > 0 if the index is found, but if I write
IF indexExisting() = 0 THEN ...
directly into the .sql file, it says
java.sql.SQLSyntaxErrorException: unexcepted token: IF
Also a stored procedure does not seem to help, as they may not contain DROP statements, as far as I read.
So a solution other than dropping / creating the index would be appreciated.
Thank you
The latest version of HSQLDB supports both:
CREATE INDEX IF NOT EXISTS myIndex ...
DROP INDEX IF EXISTS myIndex
I would like to rename an index. I've looked at the alter table documentation, but I can't figure out the syntax to simply rename an index. When doing it through the MySQL GUI, it drops the index, and creates a new one. While this works, I would like to avoid rebuilding the entire index just to change the name of an index.
[ADDITIONAL INFO]
In the alter table documentation it states
Alterations that modify only table
metadata and not table data can be
made immediately by altering the
table's .frm file and not touching
table contents. The following changes
are fast alterations that can be made
this way:
* Renaming a column or index.
However, when I tried to rename the index by editing the .frm file (on a test database) and restarting the server, it now states "Could not fetch columns" in the UI when trying to list the columns, and when trying to run a query, it returns the error "Unknown table engine ''". The .frm file has a lot of binary content. Is there a good tool for editing the binary info.
I answered this question in 2009. At that time there was no syntax in MySQL to rename an index.
Since then, MySQL 5.7 introduced an ALTER TABLE RENAME INDEX syntax.
http://dev.mysql.com/doc/refman/5.7/en/alter-table.html says in part:
RENAME INDEX old_index_name TO new_index_name renames an index. This is a MySQL extension to standard SQL. The content of the table remains unchanged. old_index_name must be the name of an existing index in the table that is not dropped by the same ALTER TABLE statement. new_index_name is the new index name, which cannot duplicate the name of an index in the resulting table after changes have been applied. Neither index name can be PRIMARY.
Earlier versions of MySQL, e.g. 5.6 and earlier, support no syntax in ALTER TABLE to rename an index (or key, which is a synonym).
The only solution was to ALTER TABLE DROP KEY oldkeyname, ADD KEY newkeyname (...).
There is no ALTER INDEX command in MySQL. You can only DROP INDEX and then CREATE INDEX with the new name.
Regarding your update above: perhaps the documentation isn't precise enough. Regardless, there's no SQL syntax to rename an index.
An index is a data structure that can be rebuilt from the data (in fact it's recommended to rebuild indexes periodically with OPTIMIZE TABLE). It takes some time, but it's a commonplace operation. Indexes data structures are separate from table data, so adding or dropping an index shouldn't need to touch the table data, as the documentation says.
Regarding the .frm file, MySQL does not support editing the .frm file. I wouldn't do it for any reason. You are 100% guaranteed to corrupt your table and make it unusable.
For MySQL 5.7:
ALTER TABLE tbl_name RENAME INDEX old_index_name TO new_index_name
For MySQL older versions:
ALTER TABLE tbl_name DROP INDEX old_index_name, ADD INDEX new_index_name (...)
See http://dev.mysql.com/doc/refman/5.7/en/alter-table.html
This question was asked ages ago, and was last updated over half a year ago.
Still I feel the need to add this tip:
If the indexed column is used elsewhere as a foreign key, you may encounter an error related to that. Doing this may help:
SET FOREIGN_KEY_CHECKS = 0;
ALTER TABLE tbl DROP INDEX index_name;
ALTER TABLE tbl ADD INDEX new_index_name (indexed_column);
SET FOREIGN_KEY_CHECKS = 1;
Hope someone finds this useful.