Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id A921BB5DCCF for ; Wed, 2 Nov 2011 11:28:32 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 64583-02 for ; Wed, 2 Nov 2011 14:28:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 4BA72B5DCCD for ; Wed, 2 Nov 2011 11:28:26 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id pA2EQplO029601; Wed, 2 Nov 2011 10:26:51 -0400 (EDT) To: Mohamed Hashim cc: tv@fuzzy.cz, ktm@rice.edu, Marcus Engene , pgsql-performance@postgresql.org Subject: Re: Performance Problem with postgresql 9.03, 8GB RAM, Quadcore Processor Server--Need help!!!!!!! In-reply-to: References: <4EAFC29A.40509@engene.se> <24830.1320154980@sss.pgh.pa.us> Comments: In-reply-to Mohamed Hashim message dated "Wed, 02 Nov 2011 12:42:20 +0530" Date: Wed, 02 Nov 2011 10:26:50 -0400 Message-ID: <29599.1320244010@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-3.101 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-1.201 X-Spam-Level: X-Archive-Number: 201111/15 X-Sequence-Number: 45526 Mohamed Hashim writes: > The below are the sample query which i put for particular one bill_id > EXPLAIN ANALYZE SELECT abd.bill_no as > bill_no,to_char(abd.bill_date,'dd/mm/yyyy') AS date,mp.product_desc as > product_desc,std.quantity,std.area,rip.price AS rate > FROM acc_bill_items_106 abi > JOIN acc_bill_details_106 abd ON abd.bill_id=abi.bill_id > JOIN stk_source ss ON ss.source_detail[1]=1 and > ss.source_detail[2]=abi.item_id > JOIN stock_transaction_detail_106 std ON std.stock_id=ss.stock_id > JOIN stock_details_106 sd106 ON sd106.stock_id=std.stock_id > JOIN master_product_106 mp ON mp.product_id= sd106.product_id > JOIN receipt_item_price_106 rip ON rip.receipt_item_id=abi.item_id > WHERE abi.bill_id=12680; All the time seems to be going into the seqscan on stk_source and its child tables. It looks like it would help if "ss.source_detail[1]=1 and ss.source_detail[2]=abi.item_id" were indexable (particularly the latter). Which probably means you need to rethink your data representation. Putting things that you need to index on into an array is not a very good design. I suppose you can do it if you're absolutely set on it (functional indexes on (source_detail[1]) and (source_detail[2])) but it appears to suck from a notational point of view too. Six months from now, when you look at this code, are you going to remember what's the difference between source_detail[1] and source_detail[2]? Not without consulting your notes, I bet. regards, tom lane