From: | "Carson, Leonard" <lcarson(at)sdsc(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: views much slower in 9.3 than 8.4 |
Date: | 2015-03-19 17:24:47 |
Message-ID: | 66DCD6CD-90FC-4BD8-BF06-E7A4EB3005EC@ucsd.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Here are the 3 views and some timing notes:
http://pgsql.privatepaste.com/decae31693#
thanks, lcarson
On Mar 18, 2015, at 3:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us<mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
"Carson, Leonard" <lcarson(at)sdsc(dot)edu<mailto:lcarson(at)sdsc(dot)edu>> writes:
There is only one server at this point. The 8.4 machine was upgraded to 9.3 about a year ago and we have no 8.4 backups so it's difficult if not impossible to recreate the 8.4 environment AFAIK. One of our developers pointed out the discrepancy in execution times. I decomposed a slow view and found out that it consists of a view calling a view calling a view (3 deep). This is the analyze explain plan of the innermost view:
http://explain.depesz.com/s/IMg
You're probably going to need to show us the actual view definitions.
I'm suspicious that the underlying cause might have to do with recent
versions being warier about optimizing sub-selects containing volatile
functions than 8.4 was. However, that theory doesn't seem to explain
the horribly bad join size estimates you're showing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Shchukin | 2015-03-19 17:30:44 | Re: [GENERAL] Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary |
Previous Message | Jake Magner | 2015-03-19 16:40:49 | Re: Merge Join chooses very slow index scan |