A bug in PostgreSQL version 9.0 and earlier versions

Recently, due to performance issues, we have changed tables with large data volumes to partition tables ). This process is also very difficult in PostgreSQL. Refer to my other article.Article.

It was a good thing to benefit the country and the people. A few days later someone found that a query for a partition table was particularly slow. After checking, we found that the query time for a data volume of about w-600w actually took 12 S-13 s. This is abnormal. After analysis, it is found that a single select max (time_stamp) from ** table; statement in this SQL statement consumes 11-12 s. Roar,This is even worse. Query and analysis results show that all partitions are queried by full table scan (full
Table scan ). This is not the case, because the time_stamp field is one of the joint primary keys.Why should it be index scan? It seems that this is why the query performance is low. The analysis is omitted for a long time. No. I have to go to maillist in postgrsql to find the answer,Alas, I found it. I wiped it. Http://archives.postgresql.org/pgsql-performance/2011-02/msg00234.php

Originally, this was a bug in postgrsql, which exists in versions 9.0 ** and earlier, version 9.0 is used. Alas. Speed download version9.1 and test the same SQL. It takes 4-5 ms to view the query and analysis. Index scanning is performed.
conclusion: Be cautious when using immature products. Fortunately, 9. 1. * release has been released in March. We can use an upgraded version to solve this problem. What should we do if there is no release?