Re: PostgreSQL OR performance

От: Tom Lane
Тема: Re: PostgreSQL OR performance
Дата: ,
Msg-id: 7426.1226768851@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: PostgreSQL OR performance  ("Віталій Тимчишин")
Ответы: Re: PostgreSQL OR performance  ("Віталій Тимчишин")
Список: pgsql-performance

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

PostgreSQL OR performance  ("Віталій Тимчишин", )
 Re: PostgreSQL OR performance  (Tom Lane, )
 Re: PostgreSQL OR performance  (Jeff Davis, )
  Re: PostgreSQL OR performance  ("Віталій Тимчишин", )
   Re: PostgreSQL OR performance  ("Helio Campos Mello de Andrade", )
    Re: PostgreSQL OR performance  ("Віталій Тимчишин", )
     Re: PostgreSQL OR performance  (Richard Huxton, )
      Re: PostgreSQL OR performance  ("Віталій Тимчишин", )
       Re: PostgreSQL OR performance  ("Віталій Тимчишин", )
        Re: PostgreSQL OR performance  ("David Wilson", )
         Re: PostgreSQL OR performance  ("Віталій Тимчишин", )
        Re: PostgreSQL OR performance  (Richard Huxton, )
         Re: PostgreSQL OR performance  ("Віталій Тимчишин", )
          Re: PostgreSQL OR performance  (Tom Lane, )
           Re: PostgreSQL OR performance  ("Віталій Тимчишин", )
     Re: PostgreSQL OR performance  ("Helio Campos Mello de Andrade", )

"=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <> writes:
> I am not. I can't see how materialize can multiply number of rows it gets
> from sort by 100.

Is it the right-hand input of a merge join?  If so you're looking at
mark/restore rescans, ie, repeated fetches of the same tuples.  There
must be a huge number of duplicate join keys in that relation to make
for such an increase though.  Normally the planner avoids putting a
table with lots of duplicates as the RHS of a merge, but if it doesn't
have good statistics for the join key then it might not realize the
problem.

            regards, tom lane


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

От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL OR performance
От: PFC
Дата:
Сообщение: Re: Improve Seq scan performance