Re: Seqscan rather than Index

От: David Brown
Тема: Re: Seqscan rather than Index
Дата: ,
Msg-id: 20041217011853.9E8FF3CADB0@svr1.postgresql.org
(см: обсуждение, исходный текст)
Ответ на: Seqscan rather than Index  (Jon Anderson)
Ответы: Re: Seqscan rather than Index  (Richard Huxton)
Список: pgsql-performance

Скрыть дерево обсуждения

Seqscan rather than Index  (Jon Anderson, )
 Re: Seqscan rather than Index  (Tom Lane, )
 Re: Seqscan rather than Index  (David Brown, )
  Re: Seqscan rather than Index  (Richard Huxton, )
   Re: Seqscan rather than Index  (Greg Stark, )
    Re: Seqscan rather than Index  (Tom Lane, )
     Re: Seqscan rather than Index  (Greg Stark, )
      Re: Seqscan rather than Index  (Tom Lane, )
    Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
     Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
      Re: Seqscan rather than Index  (Frank Wiles, )
       Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
       Re: Seqscan rather than Index  (Tom Lane, )
        Re: Seqscan rather than Index  (Frank Wiles, )
     Re: Seqscan rather than Index  (Bruno Wolff III, )
      Re: Seqscan rather than Index  ("Steinar H. Gunderson", )

> You might want to reduce random_page_cost a little.

> Keep in mind that your test case is small enough to fit in RAM and is
> probably not reflective of what will happen with larger tables.

I am also running 8.0 rc1 for Windows. Despite many hours spent tweaking various planner cost constants, I found little
effecton cost estimates. Even reducing random_page_cost from 4.0 to 0.1 had negligible impact and failed to
significantlyinfluence the planner. 

Increasing the statistics target for the last_name column to 250 or so *may* help, at least if you're only selecting
onename at a time. That's the standard advice around here and the only thing I've found useful. Half the threads in
thisforum are about under-utilized indexes. It would be great if someone could admit the planner is broken and talk
aboutactually fixing it! 

I'm unconvinced that the planner only favours sequential scans as table size decreases. In my experience so far, larger
tableshave the same problem only it's more noticeable. 

The issue hits PostgreSQL harder than others because of its awful sequential scan speed, which is two to five times
slowerthan other DBMS. The archives show there has been talk for years about this, but it seems, no solution. The
obviousthing to consider is the block size, but people have tried increasing this in the past with only marginal
success.

Regards

David


В списке pgsql-performance по дате сообщения:

От: David Brown
Дата:
Сообщение: Re: Seqscan rather than Index
От: Richard Huxton
Дата:
Сообщение: Re: Seqscan rather than Index