August 29, 2018 at 10:34 pm
Comments posted to this topic are about the item Indexing the PO
August 29, 2018 at 11:01 pm
Nice question, thanks Steve
a slight twist - If the OrderKey column is of type INT, the ALTER TABLE script will fail with error "cannot convert varchar to int"
____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
August 30, 2018 at 6:48 am
got it wrong but learned something in doing so
cheers steve
---------------------------------------------------------------------------------------
The more you know, the more you know that you dont know
August 30, 2018 at 7:25 am
Stewart "Arturius" Campbell - Wednesday, August 29, 2018 11:01 PMNice question, thanks Steve
a slight twist - If the OrderKey column is of type INT, the ALTER TABLE script will fail with error "cannot convert varchar to int"
I still had the "old" table in my playground database from a prior QOTD.
For a brief moment, I thought that was the catch that would make "The index is not created because of another error" the correct answer.
August 30, 2018 at 9:09 am
Thanks, I learned something.
- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
August 30, 2018 at 11:39 am
Heh... everytime I'm reminded of this, I end up asking myself... who would index a non-persisted column?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 30, 2018 at 12:12 pm
Jeff Moden - Thursday, August 30, 2018 11:39 AMHeh... everytime I'm reminded of this, I end up asking myself... who would index a non-persisted column?
Well, if it is a covering index, then the data doesn't need to be stored in the main table, just the index. If there is an index on the computed column it would seem valid that the data in the computed column is persisted in the index.
August 30, 2018 at 1:39 pm
Lynn Pettis - Thursday, August 30, 2018 12:12 PMJeff Moden - Thursday, August 30, 2018 11:39 AMHeh... everytime I'm reminded of this, I end up asking myself... who would index a non-persisted column?
Well, if it is a covering index, then the data doesn't need to be stored in the main table, just the index. If there is an index on the computed column it would seem valid that the data in the computed column is persisted in the index.
Hmmmm.... good point and very interesting, Lynn. That could make for a pretty decent disk space savings on longer tables not to mention a reduction in the actual width of the CI. Seems like it would also result in a memory savings to not persist the column. Got some testing to do. Thanks.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 31, 2018 at 4:01 am
I saw something interesting like this with one of Brent's demos.
Parameter from app is nvarchar()
Table is
create table Sometable (
somepk int
, someval varchar
)
Can't change the schema, but add
alter table sometable add somevalnvarchar nvarchar()
then index the new column. Can be used by the optimizer, not persisted,
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply