Re: Using quicksort for every external sort run

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Using quicksort for every external sort run
Дата
Msg-id CAM-w4HNQ6zMk-iQoMhz3OmuS714WDi9e06rJ5X9i_U2PYhqj4w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Using quicksort for every external sort run  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Using quicksort for every external sort run  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers

On Thu, Mar 10, 2016 at 1:40 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
> I was thinking about running some benchmarks on this patch, but the
> thread is pretty huge so I want to make sure I'm not missing something
> and this is indeed the most recent version.

I also ran some preliminary benchmarks just before FOSDEM and intend to get back to in after running different benchmarks. These are preliminary because it was only a single run and on a machine that wasn't dedicated for benchmarks. These were comparing the quicksort-all-runs patch against HEAD at the time without the memory management optimizations which I think are independent of the sort algorithm.

It looks to me like the interesting space to test is on fairly small work_mem compared to the data size. There's a general slowdown on 4MB-8MB work_mem when the data set is more than a gigabyte but but even in the worst case it's only a 30% slowdown and the speedup in the more realistic scenarios looks at least as big. 




I want to rerun these on a dedicated machine and with trace_sort enabled so that we can see how many merge passes were actually happening and how much I/O was actually happening.

--
greg
Вложения

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Using quicksort for every external sort run
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Freeze avoidance of very large table.