On 8 Listopad 2011, 13:15, Mohamed Hashim wrote: > Hi Sam,Tomas > > In my first post i have mentioned all how much shared (shared buffers, > effective cache size, work mem, etc.) and my OS and hardware information > and what are the basic settings i have changed Sorry, I've missed that first message - the archive did not list it for some reason. > and regarding Explain analyze i gave one sample query because if i tune > that particular table which has records almost 16crore i thought my > problem > will solve... OK, so the problem is either the WHERE conditions referencing the array column, or a bug in 9.0.x. Can't help you with the upgrade issue, but using an array like this is a bad design and will cause you all sorts of problems - why are you not using regular columns, anyway? I see you usually reference source_detail[1] - what is the expected selectivity of this condition? What portion of the table matches it? How many possible values are there? And it does not make sense to me to partition by date when you're not querying the data by date. Try this (one by one): 1) CREATE INDEX src_idx ON stk_source(source_detail[1]) for each partition 2) add a regular column source_detail_val with the value of source_detail[1] and create an index on it 3) repartition the table by source_detail[1] instead of date Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
