Date: Mon, 31 Aug 2015 12:19:23 -0700 (MST)
From: twoflower <standa.kurik@gmail.com>
To: pgsql-performance@postgresql.org
Message-ID: <1441048763332-5864080.post@n5.nabble.com>
In-Reply-To: <1441047830983-5864075.post@n5.nabble.com>
References: <1441037351126-5864045.post@n5.nabble.com>
 <55E47E97.1090202@2ndquadrant.com> <1441047830983-5864075.post@n5.nabble.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
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

And another thing which comes out as a little surprising to me - if I replace
the *date_last_updated* condition with another one, say *doc.documenttype =
4*, the query finishes immediately. *documenttype* is an unindexed integer
column.

Here's the query plan:

<http://postgresql.nabble.com/file/n5864080/qp3.png> 

What's so special about that *date_last_updated* condition that makes it so
slow to use? Is it because it involves the *date()* function call that it
makes it difficult for the planner to guess the data distribution in the
DOCUMENT table?


--
View this message in context: http://postgresql.nabble.com/Query-1-000-000-slowdown-after-adding-datetime-comparison-tp5864045p5864080.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