Re: Re: Query > 1000× slowdown after adding datetime comparison

Stefan Keller wrote
> So, if I'm understanding you correctly, we're talking solely about
> following clause in the query you gave initially:
>
> WHERE doc.date_last_updated >= date(now() - '171:00:00'::interval)
> which initially was
> WHERE documenttype = 4
> and now is being replaced by a temporary (I'd say derived) column
> WHERE updated
> ?
>
> In any case - I have to go - but run http://explain.depesz.com/ and
> give a weblink to the explain plans of your queries.

Here's the query plan for the original query I struggled with: WHERE
doc.date_last_updated >= date(now() - '171:00:00'::interval)

The original slow query with date()
<http://explain.depesz.com/d/WEy/SFfcd5esMuuI9wrLmQrZU33ma371uW2Nlh1PmeI9ZDRiAJ4wjv>

Then, just out of curiosity, I replaced the WHERE condition with another
one: WHERE doc.documenttype = 4. documenttype is an unindexed integer
column. It's fast. Here's the query plan:

date() condition replaced with documenttype = 4
<http://explain.depesz.com/d/kHG/u1dvsDyJPBK92xnKwNT3YkQsNW6WfG9aHmWAzVSOgmXikL3hiW>

Then, as David suggested, I tried to precompute the doc.date_last_updated >=
date(now() - '171:00:00'::interval). I created a new boolean temp_eval
column on the DOCUMENT table and updated the rows like this:

update "DOCUMENT" set temp_eval = date_last_updated >= date(now() -
'171:00:00'::interval);

Then I analyzed the table and modified the query to only have WHERE
temp_eval = TRUE. I expected this to be fast, but it took 41 minutes to
complete. Here's the query plan:

Precomputed column
<http://explain.depesz.com/d/2aFw/GLqQ8CMGDZOYx5134M8eallFluervKXDfOdnaz4nZTMXYNacji>



--
View this message in context:
http://postgresql.nabble.com/Query-1-000-000-slowdown-after-adding-datetime-comparison-tp5864045p5864164.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.