Date: Mon, 31 Aug 2015 12:46:56 -0700 (MST)
From: twoflower <standa.kurik@gmail.com>
To: pgsql-performance@postgresql.org
Message-ID: <1441050416677-5864088.post@n5.nabble.com>
In-Reply-To: 
 <CAKFQuwbUZLWuhoaAF7mWdmRr-6LG9NdMfsyPasXo1ZY82YVRzA@mail.gmail.com>
References: <1441037351126-5864045.post@n5.nabble.com>
 <55E47E97.1090202@2ndquadrant.com> <1441047830983-5864075.post@n5.nabble.com>
 <1441048763332-5864080.post@n5.nabble.com>
 <CAKFQuwbUZLWuhoaAF7mWdmRr-6LG9NdMfsyPasXo1ZY82YVRzA@mail.gmail.com>
Subject: =?UTF-8?Q?Re:__Re:_Query_>_1000=C3=97_slow?=
 =?UTF-8?Q?down_after_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

David G Johnston wrote
> What happens if you pre-compute the date condition and hard code it?

I created a new boolean column and filled it for every row in DOCUMENT with
*(doc.date_last_updated >= date(now() - '171:00:00'::interval))*, reanalyzed
the table and modified the query to just compare this column to TRUE. I
expected this to be very fast, considering that a (to me, anyway) similar
query also containing a constant value comparison finishes immediately.
However, the query is running now for 4 minutes already. That's really
interesting.


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