Re: SeqScan costs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SeqScan costs
Дата
Msg-id 683.1219078142@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SeqScan costs  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: SeqScan costs  (Decibel! <decibel@decibel.org>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: migrate data 6.5.3 -> 8.3.1
Следующее
От: Robert Treat
Дата:
Сообщение: Re: any psql static binary for iphone ?