Re: Weird index or sort behaviour

От: Tom Lane
Тема: Re: Weird index or sort behaviour
Дата: ,
Msg-id: 24934.1250614649@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Weird index or sort behaviour  (Tom Lane)
Ответы: Re: Weird index or sort behaviour  (Greg Stark)
Список: pgsql-performance

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

Weird index or sort behaviour  (Matthew Wakeling, )
 Re: Weird index or sort behaviour  (Tom Lane, )
  Re: Weird index or sort behaviour  (Matthew Wakeling, )
   Re: Weird index or sort behaviour  (Tom Lane, )
    Re: Weird index or sort behaviour  (Tom Lane, )
     Re: Weird index or sort behaviour  (Greg Stark, )
      Re: Weird index or sort behaviour  (Tom Lane, )
       Re: Weird index or sort behaviour  (Matthew Wakeling, )
        Re: Weird index or sort behaviour  (Tom Lane, )
         Re: Weird index or sort behaviour  (Matthew Wakeling, )
          Re: Weird index or sort behaviour  (Tom Lane, )
           Re: Weird index or sort behaviour  (Matthew Wakeling, )

I wrote:
> Matthew Wakeling <> writes:
>> Very clever. Yes, that is what is happening. I'm surprised that the system
>> doesn't buffer the inner side to avoid having to rescan each time, but
>> then I guess you would have problems if the buffer grew larger than
>> memory.

> Well, it does consider adding a Materialize node for that purpose,
> but in this case it evidently thought a sort was cheaper.

Hmmm ... actually, after looking at the code, I notice that we only
consider adding a Materialize node to buffer an inner input that is a
Sort node.  The idea was suggested by Greg Stark, if memory serves.
I wonder now if it'd be worthwhile to generalize that to consider
adding a Materialize above *any* inner mergejoin input.

            regards, tom lane


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

От: Slava Moudry
Дата:
Сообщение: Re: number of rows estimation for bit-AND operation
От: Karl Denninger
Дата:
Сообщение: Re: SQL Query Performance - what gives?