From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: 7k records into Sort node, 4.5m out? |
Date: | 2012-08-20 15:40:24 |
Message-ID: | 1059.1345477224@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2012-08-20 17:47:15 | Re: 7k records into Sort node, 4.5m out? |
Previous Message | Josh Berkus | 2012-08-19 19:53:37 | Re: 7k records into Sort node, 4.5m out? |