Re: PoC: Partial sort

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: PoC: Partial sort
Дата
Msg-id CA+TgmoYMPcbSmdZr-khRSPOH3H3H_SDd=9LjOOLk2Hvmo3OvZg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PoC: Partial sort  (Marti Raudsepp <marti@juffo.org>)
Ответы Re: PoC: Partial sort  (Marti Raudsepp <marti@juffo.org>)
Список pgsql-hackers
On Wed, Feb 5, 2014 at 6:58 PM, Marti Raudsepp <marti@juffo.org> wrote:
> I ran some synthetic benchmarks with single-column inner joins between 5
> tables, with indexes on both joined columns, using only EXPLAIN (so
> measuring planning time, not execution) in 9 scenarios to excercise
> different code paths. According to these measurements, the overhead ranges
> between 1.0 and 4.5% depending on the scenario.

Hmm, sounds a little steep.  Why is it so expensive?  I'm probably
missing something here, because I would have thought that planner
support for partial sorts would consist mostly of considering the same
sorts we consider today, but with the costs reduced by the batching.
Changing the cost estimation that way can't be that much more
expensive than what we're already doing, so the overhead should be
minimal.  What the patch is actually doing seems to be something quite
a bit more invasive than that, but I'm not sure what it is exactly, or
why.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Add CREATE support to event triggers
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Performance Improvement by reducing WAL for Update Operation