473,721 Members | 2,123 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

why this 2-column index not used

I have a composite index on two columns in a table. However, the
index is not used in a query that restricts the 2nd column to a
constant. If both columns are linked with columns in other join
tables, the index will be used.

To illustrate it with an example, I have a query like this:

select s.ticker, p.quantity
from stock s, positions p
where s.type_id = 4
and s.stock_id = p.stock_id

There is an index on stock: (stock_id, type_id). In the table stocks,
there are about 100 different type_ids evenly distributed, and ten of
thousand different stock_ids (each stock_id could map to every one of
the 100 type_ids).

From the plan, the above query does not use the index, but the
following query does use the index:

select s.ticker, p.quantity
from stock s, positions p
where s.type_id = p.pos_type_id
and s.stock_id = p.stock_id

The only difference is that in the first query, type_id is constant 4,
while in the second it is linked with another column in the second
table.

The stats are good. Is there anything else that might have caused the
above?

Sep 13 '08 #1
6 3936
Even if I add another index stock (stock_id), the first query still
doesn't use any index.

However, if the query is like this:

select s.ticker, p.quantity
from stock s, positions p
where s.stock_id = p.stock_id

The index on stock (stock) will be used (of course). If the query is
like this:

select s.ticker, p.quantity
from stock s, positions p
where s.stock_id = 101
s.type_id = 4

then the index on stock (stock_id, type_id) is used.

BTW, there is a foreign key in stock that links the stock_id field to
the positions (stock_id).

Anybody can explain the above?
Sep 13 '08 #2
"Henry J." <ta********@yah oo.comwrote in message
news:02******** *************** ***********@m45 g2000hsb.google groups.com...
>I have a composite index on two columns in a table. However, the
index is not used in a query that restricts the 2nd column to a
constant. If both columns are linked with columns in other join
tables, the index will be used.

To illustrate it with an example, I have a query like this:

select s.ticker, p.quantity
from stock s, positions p
where s.type_id = 4
and s.stock_id = p.stock_id

There is an index on stock: (stock_id, type_id). In the table stocks,
there are about 100 different type_ids evenly distributed, and ten of
thousand different stock_ids (each stock_id could map to every one of
the 100 type_ids).

From the plan, the above query does not use the index, but the
following query does use the index:

select s.ticker, p.quantity
from stock s, positions p
where s.type_id = p.pos_type_id
and s.stock_id = p.stock_id

The only difference is that in the first query, type_id is constant 4,
while in the second it is linked with another column in the second
table.

The stats are good. Is there anything else that might have caused the
above?
You are confusing the use of an index with automatically getting better
performance than not using an index. Sometimes using an index will result in
better performance, and sometimes not. If DB2 determines that it is faster
to not use an index, then it will not use one. This typically happens when
DB2 will have read every data page (rows are stored in pages) to satisfy the
query.

Keep in mind that you are returning all rows from the table (you don't
qualify which type_id or which stock_id's you want), so it is safe to assume
that DB2 will have to read not just every page, but in fact every row, to
satisfy the query.

Assuming you did a runstats as follows:
runstats on table <table-namewith distribution on key columns and indexes
all
then DB2 almost always makes the correct decision.
Sep 13 '08 #3
On Sep 13, 12:34*am, "Mark A" <some...@someon e.comwrote:
"Henry J." <tank209...@yah oo.comwrote in message

news:02******** *************** ***********@m45 g2000hsb.google groups.com...
I have a composite index on two columns in a table. *However, the
index is not used in a query that restricts the 2nd column to a
constant. *If both columns are linked with columns in other join
tables, the index will be used.
To illustrate it with an example, I have a query like this:
select s.ticker, p.quantity
from stock s, positions p
* * *where s.type_id = 4
* * * * * * * and s.stock_id = p.stock_id
There is an index on stock: (stock_id, type_id). *In the table stocks,
there are about 100 different type_ids evenly distributed, and ten of
thousand different stock_ids (each stock_id could map to every one of
the 100 type_ids).
From the plan, the above query does not use the index, but the
following query does use the index:
select s.ticker, p.quantity
from stock s, positions p
* * *where s.type_id = p.pos_type_id
* * * * * * * and s.stock_id = p.stock_id
The only difference is that in the first query, type_id is constant 4,
while in the second it is linked with another column in the second
table.
The stats are good. *Is there anything else that might have caused the
above?

You are confusing the use of an index with automatically getting better
performance than not using an index. Sometimes using an index will resultin
better performance, and sometimes not. If DB2 determines that it is faster
to not use an index, then it will not use one. This typically happens when
DB2 will have read every data page (rows are stored in pages) to satisfy the
query.

Keep in mind that you are returning all rows from the table (you don't
qualify which type_id or which stock_id's you want), so it is safe to assume
that DB2 will have to read not just every page, but in fact every row, to
satisfy the query.

Assuming you did a runstats as follows:
runstats on table <table-namewith distribution on key columns and indexes
all
then DB2 almost always makes the correct decision.
My first query is not to return all data? It's only returning on
s.type_id = 4.

Actually my questions arised when I changed the indexes on the table
stock and the same queries run more than twice as long as before.
Then I found the main index is not used at all. Since the tables are
huge (40 mil rows), I don't see why DB2 decides it's faster not to use
the index.

Maybe I should create an index on stock (type_id)? Actually it
eliminates a table scan on stock. But why it is not using (stock_id,
type_id) even though both columns are used in where clause.

I know I must have some mis-conceptions. I just don't know which ones.
Sep 13 '08 #4
On Sep 13, 10:07*am, "Henry J." <tank209...@yah oo.comwrote:
On Sep 13, 12:34*am, "Mark A" <some...@someon e.comwrote:
"Henry J." <tank209...@yah oo.comwrote in message
news:02******** *************** ***********@m45 g2000hsb.google groups.com....
>I have a composite index on two columns in a table. *However, the
index is not used in a query that restricts the 2nd column to a
constant. *If both columns are linked with columns in other join
tables, the index will be used.
To illustrate it with an example, I have a query like this:
select s.ticker, p.quantity
from stock s, positions p
* * *where s.type_id = 4
* * * * * * * and s.stock_id = p.stock_id
There is an index on stock: (stock_id, type_id). *In the table stocks,
there are about 100 different type_ids evenly distributed, and ten of
thousand different stock_ids (each stock_id could map to every one of
the 100 type_ids).
From the plan, the above query does not use the index, but the
following query does use the index:
select s.ticker, p.quantity
from stock s, positions p
* * *where s.type_id = p.pos_type_id
* * * * * * * and s.stock_id = p.stock_id
The only difference is that in the first query, type_id is constant 4,
while in the second it is linked with another column in the second
table.
The stats are good. *Is there anything else that might have caused the
above?
You are confusing the use of an index with automatically getting better
performance than not using an index. Sometimes using an index will result in
better performance, and sometimes not. If DB2 determines that it is faster
to not use an index, then it will not use one. This typically happens when
DB2 will have read every data page (rows are stored in pages) to satisfy the
query.
Keep in mind that you are returning all rows from the table (you don't
qualify which type_id or which stock_id's you want), so it is safe to assume
that DB2 will have to read not just every page, but in fact every row, to
satisfy the query.
Assuming you did a runstats as follows:
runstats on table <table-namewith distribution on key columns and indexes
all
then DB2 almost always makes the correct decision.

My first query is not to return all data? *It's only returning on
s.type_id = 4.

Actually my questions arised when I changed the indexes on the table
stock and the same queries run more than twice as long as before.
Then I found the main index is not used at all. * Since the tables are
huge (40 mil rows), I don't see why DB2 decides it's faster not to use
the index.

Maybe I should create an index on stock (type_id)? *Actually it
eliminates a table scan on stock. * But why it is not using (stock_id,
type_id) even though both columns are used in where clause.

I know I must have some mis-conceptions. *I just don't know which ones.
You should create index (type_id, stock_id) on stock.

Yonglei
Sep 14 '08 #5
On Sep 14, 10:51*am, yongl...@gmail. com wrote:
On Sep 13, 10:07*am, "Henry J." <tank209...@yah oo.comwrote:
On Sep 13, 12:34*am, "Mark A" <some...@someon e.comwrote:
"Henry J." <tank209...@yah oo.comwrote in message
>news:02******* *************** ************@m4 5g2000hsb.googl egroups.com....
I have a composite index on two columns in a table. *However, the
index is not used in a query that restricts the 2nd column to a
constant. *If both columns are linked with columns in other join
tables, the index will be used.
To illustrate it with an example, I have a query like this:
select s.ticker, p.quantity
from stock s, positions p
* * *where s.type_id = 4
* * * * * * * and s.stock_id = p.stock_id
There is an index on stock: (stock_id, type_id). *In the table stocks,
there are about 100 different type_ids evenly distributed, and ten of
thousand different stock_ids (each stock_id could map to every one of
the 100 type_ids).
From the plan, the above query does not use the index, but the
following query does use the index:
select s.ticker, p.quantity
from stock s, positions p
* * *where s.type_id = p.pos_type_id
* * * * * * * and s.stock_id = p.stock_id
The only difference is that in the first query, type_id is constant4,
while in the second it is linked with another column in the second
table.
The stats are good. *Is there anything else that might have caused the
above?
You are confusing the use of an index with automatically getting better
performance than not using an index. Sometimes using an index will result in
better performance, and sometimes not. If DB2 determines that it is faster
to not use an index, then it will not use one. This typically happenswhen
DB2 will have read every data page (rows are stored in pages) to satisfy the
query.
Keep in mind that you are returning all rows from the table (you don't
qualify which type_id or which stock_id's you want), so it is safe toassume
that DB2 will have to read not just every page, but in fact every row, to
satisfy the query.
Assuming you did a runstats as follows:
runstats on table <table-namewith distribution on key columns and indexes
all
then DB2 almost always makes the correct decision.
My first query is not to return all data? *It's only returning on
s.type_id = 4.
Actually my questions arised when I changed the indexes on the table
stock and the same queries run more than twice as long as before.
Then I found the main index is not used at all. * Since the tables are
huge (40 mil rows), I don't see why DB2 decides it's faster not to use
the index.
Maybe I should create an index on stock (type_id)? *Actually it
eliminates a table scan on stock. * But why it is not using (stock_id,
type_id) even though both columns are used in where clause.
I know I must have some mis-conceptions. *I just don't know which ones.

You should create index (type_id, stock_id) on stock.

Yonglei
I think you are right -- if I create an index stock (type_id,
stock_id), the index will be used and no more table scan is done.

I created the index on (stock_id, type_id) because stock_id is much
more selective. Can't the DB2 optimizer figure out that this index
should be used?

BTW, as (stock_id, type_id) was the only index on the table, I'm able
to get rid of the table scan by making the table volatile.

I know DB2 optimizer is good, so what do I miss?
Sep 14 '08 #6
On Sep 14, 3:35*pm, "Henry J." <tank209...@yah oo.comwrote:
On Sep 14, 10:51*am, yongl...@gmail. com wrote:
On Sep 13, 10:07*am, "Henry J." <tank209...@yah oo.comwrote:
On Sep 13, 12:34*am, "Mark A" <some...@someon e.comwrote:
"Henry J." <tank209...@yah oo.comwrote in message
news:02******** *************** ***********@m45 g2000hsb.google groups.com...
>I have a composite index on two columns in a table. *However, the
index is not used in a query that restricts the 2nd column to a
constant. *If both columns are linked with columns in other join
tables, the index will be used.
To illustrate it with an example, I have a query like this:
select s.ticker, p.quantity
from stock s, positions p
* * *where s.type_id = 4
* * * * * * * and s.stock_id = p.stock_id
There is an index on stock: (stock_id, type_id). *In the table stocks,
there are about 100 different type_ids evenly distributed, and ten of
thousand different stock_ids (each stock_id could map to every one of
the 100 type_ids).
From the plan, the above query does not use the index, but the
following query does use the index:
select s.ticker, p.quantity
from stock s, positions p
* * *where s.type_id = p.pos_type_id
* * * * * * * and s.stock_id = p.stock_id
The only difference is that in the first query, type_id is constant 4,
while in the second it is linked with another column in the second
table.
The stats are good. *Is there anything else that might have caused the
above?
You are confusing the use of an index with automatically getting better
performance than not using an index. Sometimes using an index will result in
better performance, and sometimes not. If DB2 determines that it isfaster
to not use an index, then it will not use one. This typically happens when
DB2 will have read every data page (rows are stored in pages) to satisfy the
query.
Keep in mind that you are returning all rows from the table (you don't
qualify which type_id or which stock_id's you want), so it is safe to assume
that DB2 will have to read not just every page, but in fact every row, to
satisfy the query.
Assuming you did a runstats as follows:
runstats on table <table-namewith distribution on key columns andindexes
all
then DB2 almost always makes the correct decision.
My first query is not to return all data? *It's only returning on
s.type_id = 4.
Actually my questions arised when I changed the indexes on the table
stock and the same queries run more than twice as long as before.
Then I found the main index is not used at all. * Since the tables are
huge (40 mil rows), I don't see why DB2 decides it's faster not to use
the index.
Maybe I should create an index on stock (type_id)? *Actually it
eliminates a table scan on stock. * But why it is not using (stock_id,
type_id) even though both columns are used in where clause.
I know I must have some mis-conceptions. *I just don't know which ones.
You should create index (type_id, stock_id) on stock.
Yonglei

I think you are right -- if I create an index stock (type_id,
stock_id), the index will be used and no more table scan is done.

I created the index on (stock_id, type_id) because stock_id is much
more selective. * Can't the DB2 optimizer figure out that this index
should be used?

BTW, as (stock_id, type_id) was the only index on the table, I'm able
to get rid of the table scan by making the table volatile.

I know DB2 optimizer is good, so what do I miss?
For index1 (stock_id, type_id), DB2 needs to scan the whole index and
keep keys with type_id=4, while for index2 (type_id, stock_id), it
only needs to scan portion of index where type_id=4.

That's huge difference.
Sep 14 '08 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
5735
by: Heiko | last post by:
Hello, is there any way (v$-view) to get informaion about how often an index hast been used since of starting the Database? Thanks for help Heiko
0
1045
by: Dare to be the best | last post by:
I don't understand I have this table: CREATE TABLE product ( p_id int(11) NOT NULL default '0', p_name varchar(250) NOT NULL default '', p_cat int(11) NOT NULL default '0', PRIMARY KEY (p_id), KEY pp_cat (p_cat), FULLTEXT KEY p_name (p_name)
2
1118
by: paul | last post by:
Hi, i have a table like this CREATE TABLE dbo.test ( num int NOT NULL, ename char(80), eadress char(200), archived char(1) PRIMARY KEY CLUSTERED (num) )
0
1348
by: George Essig | last post by:
I have installed tsearch2 and have noticed that the gist index used to do searches grows and grows as I update rows, delete rows, or run VACUUM FULL ANALYZE. Below are some details: PostgreSQL 7.4RC1 Red Hat 9 Table "public.series" Column | Type | Modifiers ---------------+-------------------+-------------------------------------------------------- id | integer | not null...
4
5874
by: maricel | last post by:
Could someone confirm which tablespace is being used when running ALTER & CREATE INDEX. Is it the tempspace or the tablespace where the table resides? Many thanks, maricel
14
5412
by: Sean C. | last post by:
Helpful folks, Most of my previous experience with DB2 was on s390 mainframe systems and the optimizer on this platform always seemed very predictable and consistent. Since moving to a WinNT/UDB 7.2 environment, the choices the optimizer makes often seem flaky. But this last example really floored me. I was hoping someone could explain why I get worse response time when the optimizer uses two indexes, than when it uses one. Some context:
8
5260
by: Mike | last post by:
Hello, I have a few rather urgent questions that I hope someone can help with (I need to figure this out prior to a meeting tomorrow.) First, a bit of background: The company I work for is developing a web-based application, one part of which involves allowing the user the ability to page through transaction "history" information. The _summary_ history table will have the following fields: ServiceName, Date, User-Ref1, User-Ref2,...
3
1714
by: Anton Maksimenkov | last post by:
Hello. Explain. I have table "traf_raw" contains field "sip_id" (integer). This field indexed with "CREATE INDEX traf_raw_sip ON traf_raw (sip_id)". Question. When I try to get different rows postgres use index with one "sip_id" and not use index with another "sip_id". I don't understand why it is happen, but with more complex queries Seq Scan is so slowly.
15
6478
by: rAinDeEr | last post by:
Suppose i have a table which holds thousands of records with the following structure CREATE TABLE "test "."T_CNTRY" ( "CNTRY_CDE" CHAR(2) NOT NULL , "CNTRY_NAME" VARCHAR(50) ) and i have Created an index like below ::
0
8736
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9373
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9228
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
9146
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9085
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
4762
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
3207
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2592
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2145
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.