Re: Possible Performance Regression with Transitive Comparisons vs. Constants
| От | Shaun Thomas |
|---|---|
| Тема | Re: Possible Performance Regression with Transitive Comparisons vs. Constants |
| Дата | |
| Msg-id | 506618A4.70706@optionshouse.com обсуждение исходный текст |
| Ответ на | Re: Possible Performance Regression with Transitive Comparisons vs. Constants (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Possible Performance Regression with Transitive Comparisons vs. Constants
|
| Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: