Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Apr 28, 2017 at 12:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Maybe we need another type of snapshot that would accept any
>> non-vacuumable tuple. I really don't want SnapshotAny semantics here,
> I don't, in general, share your intuition that using SnapshotAny is
> the wrong thing.
I think you are mistaken.
> We're looking up the last value in the index for
> planning purposes. It seems to me that, as far as making index scans
> more or less expensive to scan, a dead tuple is almost as good as a
> live one.
You are confusing number of tuples in the index, which we estimate from
independent measurements such as the file size, with endpoint value,
which is used for purposes like guessing whether a mergejoin will be
able to stop early. For purposes like that, we do NOT want to include
dead tuples, because the merge join is never gonna see 'em.
In short, arguing about the cost of an indexscan per se is quite
irrelevant, because this statistic is not used when estimating the
cost of an indexscan.
Or put another way: the observed problem is planning time, not that the
resulting estimates are bad. You argue that we should cut planning
time by changing the definition of the estimate, and claim that the
new definition is better, but I think you have nothing but wishful
thinking behind that. I'm willing to try to cut planning time, but
I don't want the definition to change any further than it has to.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
