Re: SeqScan costs

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I'm not necessarily opposed to making this change --- it does sound
>> kinda plausible --- but I want to see some hard evidence that it does
>> more good than harm before we put it in.

> I don't want to see this thread completely drop because it also seems pretty
> plausible to me too.

> So what kind of evidence do we need? I'm thinking a query like

> select (select count(*) from 1pagetable) as n1,
> (select count(*) from 2pagetable) as n2,
> (select count(*) from 3pagetable) as n3,
> ...
> from fairlylargetable

Well, no, because there's no freedom of choice there. What we want is
to find out how this change impacts seqscan vs indexscan choices for
small tables, and then whether those choices get better or worse.

> Perhaps what's also needed here is to measure just how accurate the cpu_*
> costs are. Perhaps they need to be raised somewhat if we're underestimating
> the cost of digging through 200 tuples on a heap page and the benefit of a
> binary search on the index tuples.

Possibly. I doubt anyone's ever taken a hard look at the cpu_xxx
values.

regards, tom lane