I have a relatively large table (81M rows) and an index on it.
I want to add a column to the existing index.
I searched for it on Google, but I couldn't find a way for it.
I've read somewhere that the only way to add a column to an index is to drop and recreate it.
However, here it says it's common practice to add columns to existing index. (Although the author doesn't recommend it.)
So, is it possible to add columns to existing index and if possible is it good practice?
It is not possible to add a new column to an existing index without dropping and recreating the index.
When Jonathan Lewis is talking about "adding a column to an existing index", he's talking about dropping the existing index and creating a new index. Note in his example, both the "original index" and "modified index" are listed with a CREATE INDEX statement. There are no ALTER INDEX statements in the example that would add a new column without dropping the old column.
Whether it is a good idea to drop & recreate the index with an additional column depends on a number of factors. As Jonathan Lewis points out, there are various situations where adding additional columns will affect the clustering factor of the index and cause some existing queries to perform more poorly. Without knowing anything about your system or the index we're talking about, it's impossible to advise.
Related
Ok, tricky question I am trying to figure out where a database schema is storing a particular pointer. I know the pointer value I just don't what table it is in or what column. I know the pointer is 123123123. How do I check all table columns to see if any of them have that value?
Thanks.
In h2 you can use fulltext search, but then you would need to add all tables in the search scope and indexing.
If you need to index only primary keys, then it might be better but you still need to come up with individual FT_CREATE_INDEX() calls for each table. You can automate this with several languages or with ETLs (like scriptella).
If you've enough disk space, you could dump a SQL from your db and use a viewer for big files like glogg.
The advantage of the first solution is no external tools but you need to work out a specific indexing script for SQL for any existing or new table. The 2nd solution is a 1 time fix.
I use SQL Search from RedGate. It's free and it helps you find any text anywhere in the database.
https://www.red-gate.com/products/?gclid=CjwKEAjwiYG9BRCkgK-G45S323oSJABnykKAE7IH_EMhnmq7OdLdXljfIkdGZrDD6OnOrT4VB0agahoCVn3w_wcB
I am trying to make a tool that will live-copy a DB from one RethinkDB host to another, however I am hung-up on the fact I can't seem to find out what is actually in each index. I have tried
r.db('db').table('table').index_list()
and
r.db('db').table('table').info()
I even tried
r.db('db').table('table').index_list().info()
But all three only returned the names of the indexes and not what fields are in them. This makes it impossible to re-create the table on the destination DB exactly the same as the source.
What am I missing here? There has to be a way to do this, or is this just something missing from RethinkDB? If so, does anyone know why?
Indexes are computed from the documents in the table. If you read all of the documents from the first table (with e.g. r.table.run()) and insert them all into the second table, then re-create all the indexes, you will have successfully re-created the table.
As usual I only get answers from people who don't read my question or who want to answer questions that weren't asked.
The solution is to parse the data from
r.db('db').table('table').index_status()
I've read many information about IOT, and now in my head gruel...
Pls, help me solve question.
Have table, that have structure:
ID (PK); ID_DRUG_NAME (a); ID_FROM (b); ID_PROVIDER (c); DELETED;
The data from this table is never deleted but only marked that are removed.
Many queries uses ID, another queries uses a,b or a,c or a,b,c.
I want recreate this table using operator ORGANIZATION INDEX.
How it will be profitable?
How to rightly create a primary key and indexes?
What pitfalls do I get?
Index-organized tables (IOT) are best used when there is a single access-path. You've identified two different lead columns, so an IOT is probably not a good choice.
The issue here is that, if you make it an IOT, you have to choose one of the two columns (ID or ID_DRUG_NAME) that you'll frequently be filtering on to index. Theoretically, you could still add a second index on an IOT, but it's almost always a bad idea. An IOT with a second index is typically performs worse than if the second index doesn't exist, even when querying against the column in the second index.
In Oracle are indexes used when an UPDATE is fired without a WHERE clause
By "used", do you mean "referred to" or "modified"?
An UPDATE without a WHERE clause boils down to an iteration over the entire table; I see no good reason why Oracle should refer to an index in this case, as there's no benefit to be had from that. (Although that's little more than a qualified guess.) nonnb is right that the index will be affected depending on what column you touch.
If you update affects indexed columns, then the index pages will need to be replaced as well.
Will Oracle use the index to find the rows being updated? With no where clause, almost certainly not.
Will Oracle have to read one or more indexes, getting blocks in consistent mode to update them? If you're updating any columns that are indexed, have function-based indexes which will result in an updated indexed value, or cause row movement among partitions, then yes, indexes "will be used."
Is there any way to force oracle to use index except Hints?
No. And if the optimizer doesn't use the index, it usually has a good reason for it. Index usage, if the index is poor, can actually slow your queries down.
Oracle doesn't use an index when it thinks the index is
disabled
invalid (for example, after a huge data load and the statistics about the index haven't been updated)
won't help (for example, when there are only two different values in 5 million rows)
So the first thing to check is that the index is enabled, then run the correct GATHER command on your index/table/schema. When that doesn't help, Oracle thinks that loading your index will actually take more time than loading the actual row values. In this case, add more columns to the index to make it appear more "diverse".
You might take a look at oracle stored outlines. You can take an existing query and create a stored outline and tweak the query just like hints. It is just very hard to use. Do some research before you decide to implement stored outlines.
You can add hints into the query that will cause it to look more favorably on one index over another index.
In general if you have collected good statistics on all the tables and indexes Oracle usually implements very good execution plans.
If your query doesn't include the indexed field in its conditions, then the DB would be foolish to use the index. Thus, I second Donnie's answer.
Yes, technically, you can force Oracle to use an index (without hints), in one scenario: if the table is an index-organized table, then logically the only way to query the table is via its index because there is no table to query.