Re: PostgreSQL OR performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



As far as i know if you created the indexes properly and postgres sees that it will give some improvement he will use those.
 - Look at the page of index creation that we may be forgeting some thing.

http://www.postgresql.org/docs/8.3/static/indexes.html

I have to go to the hospital know. Tomorrow i will take a look at the manual and try to understand all the necessary for the postgresql use an index.

Regards

On Thu, Nov 6, 2008 at 2:33 PM, Віталій Тимчишин <tivv00@xxxxxxxxx> wrote:


2008/11/6 Helio Campos Mello de Andrade <helio.campos@xxxxxxxxx>

For what i see in four OR-plan.txt tou are doing too much "sequencial scan" . Create some indexes for those tables using the fields that you use an it may help you.

OBS: If you already have lots of indexes in your tables it may be a good time for you re-think your strategy because it´s ot working.
Tips:
  1 - create indexes for the tables with the fields that you will use in the query if it is your most important query. If you have others querys that are used please post those here and we can help you to desing a better plan.

As you can see from other plans, it do have all the indexes to perform it's work fast (when given part by part). It simply do not wish to use them. My question: Is this a configuration problem or postgresql optimizer simply can't do such a query rewrite?
 
Actually I did rewrite the query to work properly as you can see from union-plan.txt. My question is if postgresql can do this automatically because such a rewrite is not always easy/possible (esp. for generated queries)?




--
Helio Campos Mello de Andrade

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux