Re: PostgreSQL OR performance

Поиск
Список
Период
Сортировка
От Віталій Тимчишин
Тема Re: PostgreSQL OR performance
Дата
Msg-id 331e40660811170152v219b5327hc1564da48dde2143@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL OR performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance


2008/11/15 Tom Lane <tgl@sss.pgh.pa.us>
"Віталій Тимчишин" <tivv00@gmail.com> 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.

OK, thanks for cleaning-up some mystery.
But, returning to original Q: Do anyone known why does it choose plan from OR-plan.txt instead of union-plan.txt? The first is cost=4588.13..960900482668.95, the latter is cost=266348.42..272953.14 according to statistics postgres have, so I suppose planner would select it if it could evaluate it.

В списке pgsql-performance по дате отправления:

Предыдущее
От: PFC
Дата:
Сообщение: Re: Performance Question
Следующее
От: PFC
Дата:
Сообщение: Re: Improve Seq scan performance