Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWUOg-0004zk-0W for pgsql-performance@arkaria.postgresql.org; Mon, 31 Aug 2015 19:05:38 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZWUOf-0006LN-I6 for pgsql-performance@arkaria.postgresql.org; Mon, 31 Aug 2015 19:05: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) (envelope-from ) id 1ZWUN2-0004Ot-MU for pgsql-performance@postgresql.org; Mon, 31 Aug 2015 19:03:56 +0000 Received: from mbob.nabble.com ([162.253.133.15]) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1ZWUMz-0000ik-5h for pgsql-performance@postgresql.org; Mon, 31 Aug 2015 19:03:55 +0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 2592C146C427 for ; Mon, 31 Aug 2015 12:00:54 -0700 (PDT) Date: Mon, 31 Aug 2015 12:03:50 -0700 (MST) From: twoflower To: pgsql-performance@postgresql.org Message-ID: <1441047830983-5864075.post@n5.nabble.com> In-Reply-To: <55E47E97.1090202@2ndquadrant.com> References: <1441037351126-5864045.post@n5.nabble.com> <55E47E97.1090202@2ndquadrant.com> Subject: =?UTF-8?Q?Re:_Query_>_1000=C3=97_slowdown_af?= =?UTF-8?Q?ter_adding_datetime_comparison?= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -0.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 Tomas Vondra-4 wrote > Please share explain plans for both the slow and the fast query. That > makes it easier to spot the difference, and possibly identify the cause. > > Also, what PostgreSQL version is this, and what are "basic" config > parameters (shared buffers, work mem)? I am running 9.4.4, here are the basic config parameters: work_mem = 32 MB shared_buffers = 8196 MB temp_buffers = 8 MB effective_cache_size = 4 GB I have run ANALYZE on all tables prior to running the queries. The query plan for the fast version (without the WHERE clause) follows: What I don't understand is the difference between the inner NESTED LOOP between the slow and the fast query plan. In the fast one, both index scans have 1000 as the actual row count. I would expect that, given the LIMIT clause. The slow query plan, however, shows ~ 75 000 000 as the actual row count. Is the extra WHERE condition the only and *plausible* explanation for this difference? David G. Johnston wrote > I would probably try something like: > > WITH docs AS ( SELECT ... WHERE date > ...) > SELECT ... FROM (translations join translation_unit) t > WHERE EXISTS (SELECT 1 FROM docs WHERE t.doc_id = docs.doc_id) > ORDER BY t.id LIMIT 1000 David, I tried this and it is probably as slow as the original query. It did not finish in 5 minutes anyway. -- View this message in context: http://postgresql.nabble.com/Query-1-000-000-slowdown-after-adding-datetime-comparison-tp5864045p5864075.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance