Message-ID: <5239F5DD.8090007@consistentstate.com>
Date: Wed, 18 Sep 2013 12:50:05 -0600
From: Brian Fehrle <brianf@consistentstate.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130311 Thunderbird/17.0.4
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-performance@postgresql.org
Subject: Re: View with and without ::text casting performs differently.
References: <5229097C.4070401@consistentstate.com>
 <1960.1378425018@sss.pgh.pa.us> <522A05E1.1070103@consistentstate.com>
 <2215.1378492532@sss.pgh.pa.us>
In-Reply-To: <2215.1378492532@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 09/06/2013 12:35 PM, Tom Lane wrote:
> Brian Fehrle <brianf@consistentstate.com> writes:
>> On 09/05/2013 05:50 PM, Tom Lane wrote:
>>> I rather doubt that the now-explicit-instead-of-implicit casts have much
>>> to do with that.  It seems more likely that you forgot to re-ANALYZE in
>>> the new database, or there are some different planner settings, or
>>> something along that line.
>> I have two versions of the view in place on the same server, one with
>> the typecasting and one without, and this is where I see the differences
>> (no ::text runs in 0.5ms and with ::text runs in 13 or so minutes with
>> nested loop), so it's all running off the same statistics on the data.
> Hm.  Can you provide a self-contained example?

I'll see what I can do to recreate this with bogus data. It's sensitive 
data that may just be some sort of anomaly in terms of the data 
distribution that is causing it.

- Brian F
>
> 			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