From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
cc: pgsql-performance@postgresql.org
Subject: Re: 7k records into Sort node, 4.5m out?
In-reply-to: <50314441.6050501@agliodbs.com>
References: <D2CA9292-023A-4DF4-82B8-6E99CE82CCB1@thebuild.com>
	<dda48e8e4cd63cc6f98f9eca78016c05.squirrel@sq.gransy.com>
	<32B51AEA-E940-40CF-BA54-C7D4E3E1F0D7@thebuild.com>
	<10304.1344910305@sss.pgh.pa.us>
	<623F2FF3-B79D-419A-929A-41C707DD5EA3@thebuild.com>
	<16268.1345063872@sss.pgh.pa.us> <502C0E6B.1040402@agliodbs.com>
	<20520.1345067076@sss.pgh.pa.us>
	<502C3DE2.9060703@agliodbs.com> <2703.1345096911@sss.pgh.pa.us>
	<50314441.6050501@agliodbs.com>
Comments: In-reply-to Josh Berkus <josh@agliodbs.com>
	message dated "Sun, 19 Aug 2012 12:53:37 -0700"
Date: Mon, 20 Aug 2012 11:40:24 -0400
Message-ID: <1059.1345477224@sss.pgh.pa.us>

Josh Berkus <josh@agliodbs.com> writes:
> I guess what I'm really not understanding is why it's calculating a cost
> of 3.7m for the index scan, and then discarding that *entire* cost and
> not including it in the total cost of the query?

It isn't ... or at least, you've offered no evidence that it is.
It's discounting some fraction of the cost on the (apparently correct)
basis that the merge won't read that input all the way to the end.
Whether it's discounted by an appropriate fraction is hard to tell
from the information given.  The actual rows count is about a quarter
the whole-scan estimate, so a multiplier of 0.25 seems right in
hindsight, and that seems to match up roughly right with the mergejoin
cost estimate --- but not knowing the actual table size, there's a lot
of uncertainty here.

			regards, tom lane