From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Carson, Leonard" <lcarson@sdsc.edu>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: views much slower in 9.3 than 8.4
In-reply-to: <66DCD6CD-90FC-4BD8-BF06-E7A4EB3005EC@ucsd.edu>
References: <1265DCF8-67C3-4FF3-8737-B2798EE06E25@ucsd.edu>
 <9C8B9906-D76A-48EE-AED9-516AFD3A4725@ucsd.edu>
 <5424.1426718490@sss.pgh.pa.us>
 <66DCD6CD-90FC-4BD8-BF06-E7A4EB3005EC@ucsd.edu>
Comments: In-reply-to "Carson, Leonard" <lcarson@sdsc.edu>
 message dated "Thu, 19 Mar 2015 17:24:47 -0000"
Date: Thu, 19 Mar 2015 19:04:22 -0400
Message-ID: <13022.1426806262@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

"Carson, Leonard" <lcarson@sdsc.edu> writes:
> Here are the 3 views and some timing notes:
> http://pgsql.privatepaste.com/decae31693#

That doesn't really leave us any wiser than before, unfortunately.

It's clear that the root of the problem is the drastic underestimation of
the size of the rq/a join, but it's not clear why that's happening, nor
why 8.4 would not have fallen into the same trap.

Would it be possible to provide the data in the join columns involved in
that part of the query?  To wit
requests.account_id
requests.start_date
allocations.account_id
allocations.initial_start_date
allocations.resource_id

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance