From: Tom Lane <tgl@sss.pgh.pa.us>
To: Scott Marlowe <scott.marlowe@gmail.com>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: subselect requires offset 0 for good performance.
In-reply-to: 
 <CAOR=d=02KtqKwD36UCu1wV3krbnQ_3T5yjjihONauCp_OhvwKA@mail.gmail.com>
References: 
 <CAOR=d=2Fq-TzwzRf92BOeeHGqhkPXVG5_zs+_aR690ZxPp3JAg@mail.gmail.com>
 <4522.1375400642@sss.pgh.pa.us>
 <CAOR=d=3UVax7k_nT7Gm+Y2N0=0WZekT2dyOzxWM4wjsryfQL=Q@mail.gmail.com>
 <CAOR=d=02KtqKwD36UCu1wV3krbnQ_3T5yjjihONauCp_OhvwKA@mail.gmail.com>
Comments: In-reply-to Scott Marlowe <scott.marlowe@gmail.com>
 message dated "Fri, 02 Aug 2013 11:08:34 -0600"
Date: Fri, 02 Aug 2013 15:31:18 -0400
Message-ID: <6895.1375471878@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Scott Marlowe <scott.marlowe@gmail.com> writes:
> I extracted all the data like so:
> select * into dba.pp_test_wide from original table;
> and get this query plan from explain analyze:
> http://explain.depesz.com/s/EPx which takes 20 minutes to run.
> If I extract it this way:
> select tree_sortkey, product_name, deleted_at into db.pp_test_3col
> from original table;
> I get this plan: http://explain.depesz.com/s/gru which gets a
> materialize in it, and suddenly takes 106 ms.

There's no reason why suppressing some unrelated columns would change the
rowcount estimates, but those two plans show different rowcount estimates.

I suspect the *actual* reason for the plan change was that autovacuum had
had a chance to update statistics for the one table, and not yet for the
other.  Please do a manual ANALYZE on both tables and see if there's
still a plan difference.

			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