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

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Дата
Msg-id cab5f03f-42b4-ee56-d295-0d4903579986@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [PATCH] Incremental sort (was: PoC: Partial sort)  (James Coleman <jtc331@gmail.com>)
Ответы Re: [PATCH] Incremental sort (was: PoC: Partial sort)  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список pgsql-hackers
On 09/06/2018 08:04 PM, James Coleman wrote:
> I disagree because it's not ideal to basically have to append pk to
> every index in the system just to get the ability to tie-break when
> there's actually very low likelihood of ties anyway.
> 
> A similar use case is trying to batch through a result set, in which
> case you need a stable sort as well.
> 
> The benefit is retaining the generality of indexes (and saving space in
> them etc.) while still allowing using them for more specific sorts. Any
> time you paginate or batch this way you benefit from this, which in many
> applications applies to a very high percentage of indexes.
> 

I 100% with this.

I see incremental sort as a way to run queries with fewer indexes that
are less query-specific, while still benefiting from them. Which means
lower overhead when writing data, lower disk space usage, and so on.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Restricting maximum keep segments by repslots
Следующее
От: Tom Lane
Дата:
Сообщение: Re: *_to_xml() should copy SPI_processed/SPI_tuptable