From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Jeremy Harris <jgh(at)wizmail(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BRIN indexes for MAX, MIN, ORDER BY? |
Date: | 2015-09-29 18:38:51 |
Message-ID: | CANP8+jJ0Z2c3LNY4Lne+OkpxN1yasy-cHDbAXSJ==7iY9MvrDA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29 September 2015 at 13:20, Jeremy Harris <jgh(at)wizmail(dot)org> wrote:
> On 27/09/15 21:58, Gavin Wahl wrote:
> > Somewhat harder but still possible would be using BRIN indexes to
> > accelerate ORDER BY. This would require a sorting algorithm that can take
> > advantage of mostly-sorted inputs. You would sort the page ranges by
> their
> > minimum or maximum value, then feed the sorting algorithm in that order.
>
> An internal merge sort does well with partially-sorted input.
>
Yes, the $SUBJECT would be a valid use for BRIN.
And also in general for sorts, leading to an optimization of merge joins
using BRIN indexes.
All this was foreseen in the original design; if it really was trivial it
would be in 9.5 already...
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-29 18:48:58 | Idea for improving buildfarm robustness |
Previous Message | Simon Riggs | 2015-09-29 18:34:12 | Re: On-demand running query plans using auto_explain and signals |