Im looking at an application where I will be doing quite a few SELECTs where I am trying to find column_a = x AND column_b = y.
Is the correct to create that index that something like the following?
CREATE INDEX index_name ON table (column_a, column_b)
Yes.
Related
I have a computed column created with the following line:
alter table tbPedidos
add restricoes as (cast(case when restricaoLicenca = 1 or restricaoLote = 1 then 1 else 0 end as bit))
But, now I need to change this column for something like:
alter table tbPedidos
alter column restricoes as (cast(case when restricaoLicenca = 1 or restricaoLote = 1 or restricaoValor = 1 then 1 else 0 end as bit))
But it's not working. I'm trying to input another condition to the case statement, but it's not working.
Thanks a lot!
Something like this:
ALTER TABLE dbo.MyTable
DROP COLUMN OldComputedColumn
ALTER TABLE dbo.MyTable
ADD OldComputedColumn AS OtherColumn + 10
Source
If you're trying to change an existing column, you can't use ADD. Instead, try this:
alter table tbPedidos
alter column restricoes as
(cast(case when restricaoLicenca = 1 or restricaoLote = 1 or restricaoValor = 1
then 1 else 0 end as bit))
EDIT: The above is incorrect. When altering a computed column the only thing you can do is drop it and re-add it.
This is one of those situations where it can be easier and faster to just use the diagram feature of SQL Server Management Studio.
Create a new diagram, add your table, and choose to show the formula column in the diagram's table view.
Change the columns formula to an empty string ('') or something equally innocuous (probably such that you don't change the column's datatype).
Save the diagram (which should save the table).
Alter your function.
Put the function back in the formula for that column.
Save once again.
Doing it this way in SSMS will retain the ordering of the columns in your table, which a simple drop...add will not guarantee. This may be important to some.
Another thing that might be helpful to someone is how to modify a function that's a calculated column in a table (Following query is for SQL):
ALTER <table>
DROP COLUMN <column>
ALTER FUNCTION <function>
(
<parameters>
)
RETURNS <type>
BEGIN
...
END
ALTER <table>
ADD <column> as dbo.<function>(parameters)
Notes:
Parameters can be other columns from the table
You may not be able to run all these queries at once, I had trouble with this. Run them one at a time
SQL automatically populates calculated columns, so dropping and adding won't affect data (I was unaware of this)
Hi i am a bit confused about the handling of indexes in postgres. I use the 9.6 version. From my understanding after reading postgres docs and answers from stackoverflow i want to verify the following:
postgres does not support indexes with the classic notion
all indexes in postgres are non-clustered indexes
indexes does not allocate any new space but apply a sort on the table
thats way after create index a CLUSTER command shall follow.
in the docs it is stated that after updates/inserts on table the index is updated automatically
Show i created a table with col1,col2,col3,col4 and the an index based on col2, col3. Selects that have to do with col2, col3 became 15 times faster.
When i execute select * from table then results are displayed first sorted based on col2 and then based on col3.
When i add a new row in the table (with a col2 value (test_value) that already existed), this row went at the end of the table (this was checked with : select * from table).
1) Did the index got updated with this new entry automatically even if the select all showed the row at the end?
2) If a execute a query will all the rows that have the test_value on col2 what will happen? Will i get all the results through the index?
There are some wrong assumptions here.
The most important is: The order of the rows in a select is indeterminate unless you include ORDER BY. So you can get any result db engine decide is the faster way to get the data. So if select * from table return the last inserted element at the end, that doesn't tell you anything regarding the index.
How Rows are stored and Index information are separate things
1) Yes, index was updated after insert.
2) Yes, because index was already update.
I can't understand why my query is doing a sequential scan.
select columns
from table
where (column_1 ilike '%whatever%' or column_2 ilike '%whatever%')
I have an index on both column_1 and column_2.
The cardinality on both columns is very high.
My table is roughly 25 million rows.
What do you think I might be doing wrong? No matter what I do, it always does a sequential scan.
Edit #1:
My index looks like this:
Create index xxx on table (column_1, column_2);
Edit #2:
Changing my sql query to
select columns
from table
where (column_1 ilike 'whatever%' and column_2 ilike 'whatever%')
still made my query use a sequential scan. I got the same result when I just used like instead of ilike. But this query:
select columns
from table
where (column_1 = 'whatever' and column_2 = whatever)
made my query use an index scan and my query went much faster :)
Two Reasons:
Your query does a OR condition in which index can't be used.
You are doing a ilike on "%xyz%". This can't use any help of sorted(i.e. indexed) data.
--
Edit: See if you can have like on "xyz%". Then index can be used if you do a separate condition on both columns (and separate index on both)
Edit2: By the query, the thing you are trying to do looks like Full Text Search. For that you would need search indexing techniques (Read Elasticsearch, Sphinx, Solr)
I need to create am index in SQL however it needs to display the records by entering only a part of the name. The index should be created to retrieve the student information using part of the student name (i.e. if the name if Johnanesburg; the user can input John)
I used the syntax below but it wont work
create index Student ON Student(SName)
SELECT * FROM Student WHERE StRegNo LIKE A%
go
I think your problem is here: A%
Try wrapping it in apostrophes.
SELECT *
FROM Student
WHERE StRegNo LIKE 'A%'
Also, you may want a GO statement after you create your index.
The index you are creating over SName will not provide as much benefit for the select statement you are running as one created over StRegNo. Assuming that StRegNo is the primary key on the Student table you could try:
CREATE CLUSTERED INDEX IX_Student on Student(StRegNo)
SELECT *
FROM Student
WHERE StRegNo LIKE 'A%'
However it appears that the SQL you have provided is at odds with your question. If you want to search based on student name then you might want the following instead.
CREATE NONCLUSTERED INDEX IX_Student on Student(SName)
SELECT *
FROM Student
WHERE SName LIKE 'A%'
Ardman got it right regarding your query %A => '%A'. Now as for the index, that's another story that no index can help you with at the time, neither can full text search. If you want to look for names starting with #A (i.e. John%), an ordered index could help but otherwise (i.e. %bur%), you will go for a full table scan !
I have a table which has a bunch of columns but the two relevant ones are:
Due_Amount MONEY
Bounced_Due_Amount MONEY
I have a SQL query like the following
SELECT * FROM table WHERE (Due_Amount > 0 OR Bounced_Due_Amount > 0)
Would the best index to put on this table for SQL Server 2008 be an index which includes both columns in the index, or should I put an separate index on each column?
An Index can't be used on an OR like that. try this:
SELECT * FROM table WHERE Due_Amount > 0
UNION ALL
SELECT * FROM table Bounced_Due_Amount > 0
--use "UNION" if Due_Amount and Bounced_Due_Amount could both >0 at any one time
have an index on Due_Amount and another on Bounced_Due_Amount.
It might be better to redesign your table. Without knowing your business logic or table, I'm going to guess that you could have a "Bounced" Y/N or 1/0 char/bit column and just a "Due_Amount" column. Add an index on that "Due_Amount" and the query would just be:
SELECT * FROM table WHERE Due_Amount > 0
you could still differentiate between a Bounced or not row. This will not work if you need to have both a bounced and non-bounced due amount at the same time.
My guess is that you would be better off with an index on each individual column. Having it on both won't help any more than having it on just the first column unless you have other queries that would use the compound index.
Your best bet is to try the query with an index on one column, an index on the other column, and two indexes - one on each column. Do some tests with each (on real data, not test data) and see which works best. Take a look at the query plans to understand why.
Depending on the specific data (both size and cardinality) SQL Server may end up using one, both, or possibly even neither index. The only way to know for sure is to test them each.
Technically, you can have an index on a persisted computed column and use the computed column instead of the OR condition in the query, see Creating Indexes on Computed Columns:
alter table [table] add Max_Due_Amount as
case
when Due_Amount > Bounced_Due_Amount the Due_Ammount
else Bounced_Due_Amount
end
persisted;
go
create index idxTableMaxDueAmount on table (Max_Due_Amount );
go
SELECT * FROM table WHERE Max_Due_Amount > 0;
But in general I'd recommend using the UNION approach like KM suggested.
Specifically for this query, it would be best to create an index on both columns in the order they are used in the where clause. Otherwise the index might not be used.