От: Jim C. Nasby
Тема: Re: Sort and index
Дата: ,
Msg-id: 20050514133722.GO49630@decibel.org
(см: обсуждение, исходный текст)
Ответ на: Re: Sort and index  (Manfred Koizar)
Список: pgsql-performance

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

Sort and index  (Andrei Gaspar, )
 Re: Sort and index  ("Dave Held", )
  Re: Sort and index  (Andrei Gaspar, )
  Re: Sort and index  (Michael Fuhr, )
   Re: Sort and index  (Andrei Gaspar, )
  Re: Sort and index  ("Jim C. Nasby", )
   Re: Sort and index  (Tom Lane, )
    Re: Sort and index  ("Jim C. Nasby", )
     Re: Sort and index  ("Jim C. Nasby", )
      Re: Sort and index  (Tom Lane, )
       Re: Sort and index  ("Jim C. Nasby", )
        Re: Sort and index  (Tom Lane, )
         Re: Sort and index  ("Jim C. Nasby", )
          Re: Sort and index  (Manfred Koizar, )
           Re: Sort and index  ("Jim C. Nasby", )
            Re: Sort and index  (Manfred Koizar, )
             Re: Sort and index  ("Jim C. Nasby", )

On Thu, May 12, 2005 at 08:54:48PM +0200, Manfred Koizar wrote:
> On Wed, 11 May 2005 16:15:16 -0500, "Jim C. Nasby" <>
> wrote:
> >> This is divided by the number of index columns, so the index correlation
> >> is estimated to be 0.219.
> >
> >That seems like a pretty bad assumption to make.
>
> Any assumption we make without looking at entire index tuples has to be
> bad.  A new GUC variable secondary_correlation introduced by my patch at
> least gives you a chance to manually control the effects of additional
> index columns.

It seems it would be much better to gather statistics on any
multi-column indexes, but I know that's probably beyond what's
reasonable for your patch.

Also, my data (http://stats.distributed.net/~decibel) indicates that
max_io isn't high enough. Look specifically at timing2.log compared to
timing.log. Thouggh, it is possibile that this is because of having
random_page_cost set to 1.1 (if I set it much higher I can't force the
index scan because the index estimate actually exceeds the cost of the
seqscan with the disable cost added in).

> >It depends on the patches, since this is a production machine. Currently
> >it's running 7.4.*mumble*,
>
> The patch referenced in
> http://archives.postgresql.org/pgsql-hackers/2003-08/msg00931.php is
> still available.  It doesn't touch too many places and should be easy to
> review.  I'm using it and its predecessors in production for more than
> two years.  Let me know, if the 74b1 version does not apply cleanly to
> your source tree.

Looks reasonable; I'll give it a shot on 8.0 once I have replication
happening.
--
Jim C. Nasby, Database Consultant               
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


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

От: "Joel Fradkin"
Дата:
Сообщение: Re: ok you all win what is best opteron (I dont want a hosed system again)
От: Josh Berkus
Дата:
Сообщение: Re: ok you all win what is best opteron (I dont want a hosed system again)