User-Agent: K-9 Mail for Android
In-Reply-To: <53AC8203.5030809@optionshouse.com>
References: <53AB2CB1.8080201@comcast.net> <53AB35CC.10202@optionshouse.com>
 <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com>
 <CAMkU=1yxskTJ8ZQQZvBqJ82Jk_R_NoeuCKkYv+8aunT191=Htw@mail.gmail.com>
 <53AC8203.5030809@optionshouse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Subject: Re: how to improve perf of 131MM row table?
From: Aaron Weber <aweber@comcast.net>
Date: Thu, 26 Jun 2014 16:43:47 -0400
To: Shaun Thomas <sthomas@optionshouse.com>,Jeff Janes <jeff.janes@gmail.com>
CC: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-ID: <793dbf54-9aee-41c7-8fdb-613b800ba80d@email.android.com>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


>I'm curious to see if Aaron can test his structure on 9.3 with the 
>original data and WHERE clause and see if the planner still goes for
>the 
>terrible plan. If it does, that would seem like an obvious planner
>tweak 
>to me.

I will try to spin up a test 9.3 db and run the same queries to see if this is the case.   Least I can do in return for the help. 


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