Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bv6Z3-0004yA-Ei for pgsql-performance@arkaria.postgresql.org; Fri, 14 Oct 2016 17:46:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bv6Z3-0000Ws-1M for pgsql-performance@arkaria.postgresql.org; Fri, 14 Oct 2016 17:46:37 +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 1bv6Z2-0000Wm-MN for pgsql-performance@postgresql.org; Fri, 14 Oct 2016 17:46:36 +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 1bv6Yz-0003Eh-P5 for pgsql-performance@postgresql.org; Fri, 14 Oct 2016 17:46:36 +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 u9EHkVD3012359; Fri, 14 Oct 2016 13:46:31 -0400 From: Tom Lane To: Kyle Moser cc: pgsql-performance@postgresql.org Subject: Re: Hibernate generated query slow compared to 'equivalent' hand written one In-reply-to: References: Comments: In-reply-to Kyle Moser message dated "Fri, 14 Oct 2016 13:27:04 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12357.1476467191.1@sss.pgh.pa.us> Date: Fri, 14 Oct 2016 13:46:31 -0400 Message-ID: <12358.1476467191@sss.pgh.pa.us> X-Pg-Spam-Score: -2.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 Kyle Moser writes: > The depesz link for explain (analyze, buffers) is shown below for 3 > different queries. The first two queries show a log dump of the postgres > log, showing a query that was generated by Java Hibernate. The third query > was one I wrote and ran in pgadmin that I think is similar to what > Hibernate is doing. It's not all that similar: according to the EXPLAIN output, the condition Hibernate is generating is Filter: ((FK_USER)::numeric = ANY ('{213,382,131,...,717}'::numeric[])) whereas your handwritten query is generating Index Cond: (fk_user = ANY ('{70,150,1248,1269,1530,...,199954}'::bigint[])) IOW, Hibernate is telling the server that the parameters it's supplying are NUMERIC not INTEGER, which results in a query using numeric_eq, which can't be indexed by a bigint index. If you can't find a hammer big enough to persuade Hibernate that it's dealing with integers/bigints rather than numerics, you could probably regain most of the performance by creating an index on (FK_USER::numeric). BTW, why is one of your EXPLAINs showing the identifiers in upper case and the other in lower case? One could be forgiven for wondering if these were really against the same data. 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