From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | James Coleman <jtc331(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Subject: | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Date: | 2018-09-06 20:34:33 |
Message-ID: | cab5f03f-42b4-ee56-d295-0d4903579986@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-06 20:40:00 | Re: *_to_xml() should copy SPI_processed/SPI_tuptable |
Previous Message | Peter Eisentraut | 2018-09-06 20:32:21 | Re: [HACKERS] Restricting maximum keep segments by repslots |