Re: Postgres not using indexes
От | Pavel Stehule |
---|---|
Тема | Re: Postgres not using indexes |
Дата | |
Msg-id | AANLkTin4YBeRku4kY3HeRf+QWHJezri3RHA-QBBwRkVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Postgres not using indexes (Lawrence Cohan <LCohan@web.com>) |
Ответы |
Re: Postgres not using indexes
|
Список | pgsql-bugs |
Hello 2011/3/30 Lawrence Cohan <LCohan@web.com>: > We have a huge performance issues in Postgres that surfaced due to existi= ng > indexes not being used like in the example below in both 8.35 and 9.0 > versions. > > > > Client_Orders table with and int ID as PK which is the order_id and index= ed > =E2=80=93 about 155,000 rows > > Order_Items table with and int ID primary key and INDEX on Order_id (int) > matching the ID in the above client_orders table. =E2=80=93 about 33 mill= ion rows > > > > A query like below takes almost ten minutes to complete however the result > set is 33768 rows and Total query runtime: 427539 ms.!!! This is due to t= he > fact that the index on Order_Items it is NOT used and a sequence scan is > done instead but this is obviously not acceptable from performance point = of > view. If I add a LIMIT 1000 for instance then the index is used and query > returns results in no time as expected but as soon as I go higher in the > limit to a few thousands then the index on Order_Items.Order_id is no lon= ger > used =E2=80=93 why??? Is there any way to force Postgres to use the exist= ing indexes > instead of table seq scan which is deadly? > > > > select oi.id from order_items oi INNER JOIN client_orders co ON oi.order_= id > =3D co.id > > Do you do a ANALYZE and VACUUM. Can you send a result of EXPLAIN ANALYZE SELECT ... Please, do ANALYZE and VACUUM first. regards Pavel Stehule > > Regards, > > Nenea Nelu. > > > > ________________________________ > Attention: > The information contained in this message and or attachments is intended > only for the person or entity to which it is addressed and may contain > confidential and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance upon, > this information by persons or entities other than the intended recipient= is > prohibited. If you received this in error, please contact the sender and > delete the material from any system and destroy any copies. >
В списке pgsql-bugs по дате отправления: