Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bDYrU-0003GG-3C for pgsql-performance@arkaria.postgresql.org; Thu, 16 Jun 2016 15:05:40 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bDYrT-00044b-FZ for pgsql-performance@arkaria.postgresql.org; Thu, 16 Jun 2016 15:05:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bDYrS-00044L-SB for pgsql-performance@postgresql.org; Thu, 16 Jun 2016 15:05:38 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bDYrO-00026p-To for pgsql-performance@postgresql.org; Thu, 16 Jun 2016 15:05:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u5GF5WlZ020335; Thu, 16 Jun 2016 11:05:32 -0400 From: Tom Lane To: meike.talbach@women-at-work.org cc: pgsql-performance@postgresql.org Subject: Re: Index not used In-reply-to: References: Comments: In-reply-to meike.talbach@women-at-work.org message dated "Thu, 16 Jun 2016 09:58:46 +0200" Date: Thu, 16 Jun 2016 11:05:32 -0400 Message-ID: <20334.1466089532@sss.pgh.pa.us> X-Pg-Spam-Score: -3.3 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org meike.talbach@women-at-work.org writes: > When I query this through pgsql, the queries are fast as expected. > select * from push_topic where guid = 'DD748CCD-B8A4-3B9F-8F60-67F1F673CFE5' > Index Scan using push_topic_idx_topicguid on push_topic (cost=0.42..8.44 rows=1 width=103) (actual time=0.117..0.121 rows=1 loops=1) > Index Cond: ((guid)::bpchar = 'DD748CCD-B8A4-3B9F-8F60-67F1F673CFE5'::bpchar) > Buffers: shared hit=3 read=1 > Total runtime: 0.191 ms > However when I run the exact query through a different application (CodeSynthesis ORM) the query is very slow (~ 115ms logged) > I noted this is due to a sequential scan happening on the table instead of an index scan. It looks like what that app is actually issuing is something different from what you tested by hand, to wit select * from push_topic where guid = 'DD748CCD-B8A4-3B9F-8F60-67F1F673CFE5'::text which causes the comparison to be resolved as texteq not bpchareq, ie you effectively have select * from push_topic where guid::text = 'DD748CCD-B8A4-3B9F-8F60-67F1F673CFE5'::text and that doesn't match a bpchar index. If you can't persuade the app to label the comparison value as bpchar not text, the easiest fix would be to create an additional index on "guid::text". regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance