Re: Wrong plan sequential scan instead of an index one

От: Michael Fuhr
Тема: Re: Wrong plan sequential scan instead of an index one
Дата: ,
Msg-id: 20070330104611.GA1540@winnie.fuhr.org
(см: обсуждение, исходный текст)
Ответ на: Re: Wrong plan sequential scan instead of an index one  (Gaetano Mendola)
Ответы: Re: Wrong plan sequential scan instead of an index one  (Michael Fuhr)
Re: Wrong plan sequential scan instead of an index one  (Gaetano Mendola)
Список: pgsql-performance

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

Wrong plan sequential scan instead of an index one  (Gaetano Mendola, )
 Re: Wrong plan sequential scan instead of an index one  ("Claus Guttesen", )
  Re: Wrong plan sequential scan instead of an index one  (Gaetano Mendola, )
   Re: Wrong plan sequential scan instead of an index one  (Michael Fuhr, )
    Re: Wrong plan sequential scan instead of an index one  (Michael Fuhr, )
     Re: Wrong plan sequential scan instead of an index one  (Gaetano Mendola, )
      Re: Wrong plan sequential scan instead of an index one  (Matteo Beccati, )
    Re: Wrong plan sequential scan instead of an index one  (Gaetano Mendola, )
 Re: Wrong plan sequential scan instead of an index one  (Richard Huxton, )
  Re: Wrong plan sequential scan instead of an index one  (Gaetano Mendola, )
   Re: Wrong plan sequential scan instead of an index one  (Richard Huxton, )
   Re: Wrong plan sequential scan instead of an index one  (, )
 Re: Wrong plan sequential scan instead of an index one  (Richard Huxton, )
  Re: Wrong plan sequential scan instead of an index one  (Tom Lane, )
   Re: Wrong plan sequential scan instead of an index one [8.2 solved it]  (Gaetano Mendola, )

On Fri, Mar 30, 2007 at 12:08:26PM +0200, Gaetano Mendola wrote:
> Claus Guttesen wrote:
> > Try changing random_page_cost from the default 4 to 2 in postgresql.conf:
> >
> > random_page_cost = 2
>
> I have tuned that number already at 2.5, lowering it to 2 doesn't change
> the plan.

The following 19-fold overestimate is influencing the rest of the
plan:

  ->  Seq Scan on l_pvcp  (cost=0.00..2.17 rows=19 width=4) (actual time=0.066..0.081 rows=1 loops=1)
        Filter: (value ~~* '%pi%'::text)

Have you tried increasing the statistics target on l_pvcp.value?
I ran your queries against canned data in 8.2.3 and better statistics
resulted in more accurate row count estimates for this and other
parts of the plan.  I don't recall if estimates for non-leading-character
matches in earlier versions can benefit from better statistics.

--
Michael Fuhr


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

От: Erik Jones
Дата:
Сообщение: Re: Shared buffers, db transactions commited, and write IO on Solaris
От: Xiaoning Ding
Дата:
Сообщение: scalablility problem