Re: SeqScan costs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SeqScan costs
Date
Msg-id 683.1219078142@sss.pgh.pa.us
Whole thread Raw
In response to Re: SeqScan costs  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: SeqScan costs  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: migrate data 6.5.3 -> 8.3.1
Next
From: Robert Treat
Date:
Subject: Re: any psql static binary for iphone ?