Re: [PATCH] Incremental sort (was: PoC: Partial sort)

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Дата
Msg-id CANP8+jLw+WQEUN5zZwQ_egr2WSbsR2bWqY79fS5BzAMJmLJCDA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Incremental sort (was: PoC: Partial sort)  (James Coleman <jtc331@gmail.com>)
Ответы Re: [PATCH] Incremental sort (was: PoC: Partial sort)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On Mon, 24 Jun 2019 at 18:01, James Coleman <jtc331@gmail.com> wrote:
On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs <simon@2ndquadrant.com> wrote:

> What is the specific use case for this? This sounds quite general case.

They are both general cases in some sense, but the concerns lie mostly
with what happens when they're unexpectedly encountered. For example,
if the expected row count or group size is off by a good bit and we
effectively have to perform a sort of all (or most) possible rows.

If we can get the performance to a point where that misestimated row
count or group size doesn't much matter, then ISTM including the patch
becomes a much more obvious total win.

I was trying to think of ways of using external information/circumstance to knowingly avoid negative use cases. i.e. don't treat sort as a black box, use its context.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Solutions for the Enterprise

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Remove HeapTuple and Buffer dependency for predicate lockingfunctions
Следующее
От: Amit Khandekar
Дата:
Сообщение: Re: Minimal logical decoding on standbys