pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Shaun Thomas <sthomas@optionshouse.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Possible Performance Regression with Transitive Comparisons vs. Constants
Date: Fri, 28 Sep 2012 16:37:40 -0500
Message-ID: <506618A4.70706@optionshouse.com> (raw)
In-Reply-To: <14848.1348864525@sss.pgh.pa.us>
References: <5065F910.5040504@optionshouse.com>
	<14848.1348864525@sss.pgh.pa.us>

On 09/28/2012 03:35 PM, Tom Lane wrote:

> 9.1.what?  For me, 8.2.23 and 9.1.6 produce the same plan and just
> about the same runtime for your query 1.

I withdraw that part of my question. I apparently didn't look closely 
enough at the actual output. I was basing the version assumption on the 
query speed on the new server, when it was probably due to cache effects.

The first part of the question stands, though... Why isn't the optimizer 
substituting these values? a.created_date should be exactly equivalent 
to '2012-05-05', but it's clearly not being treated that way.

With the full substitutions, I'm seeing things like this:

http://explain.depesz.com/s/3T4

With the column names, it's this:

http://explain.depesz.com/s/Fq7

This is on 8.2, but the behavior is the same on 9.1. From 130s to 23s 
simply by substituting the constant wherever the column name is 
encountered. For reference, the queries are, slow:

select a.id, f.ezorder_id
   from reporting.account a
   join ezorder f on f.account_id = a.account_id
  where a.process_date = '2012-09-27'
    and f.date_created between a.process_date - interval '6 months'
        and a.process_date
    and a.row_out is null

And fast:

select a.id, f.ezorder_id
   from reporting.account a
   join ezorder f on f.account_id = a.account_id
  where a.process_date = '2012-09-27'
    and f.date_created between '2012-09-27'::date - interval '6 months'
        and '2012-09-27'
    and a.row_out is null

We discovered this during the upgrade, but it seems to equally apply to 
both 8.2 and 9.1. I've been telling the devs to replace any of these 
they find all day. I can't quite say why we never "noticed" this before, 
but it got exposed today pretty plainly. If this were a compiler, I'd 
have expected it to treat the values as equivalent, but that's clearly 
not what's happening.

-- 
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas@optionshouse.com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email




view thread (4+ messages)  latest in thread

Message-ID: <506618A4.70706@optionshouse.com>
Permalink:  ../506618A4.70706@optionshouse.com/
Also on:    postgresql.org/message-id/506618A4.70706@optionshouse.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: sthomas@optionshouse.com, tgl@sss.pgh.pa.us
  Subject: Re: Possible Performance Regression with Transitive Comparisons vs. Constants
  In-Reply-To: <506618A4.70706@optionshouse.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox