From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Gavin Wahl <gavinwahl(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BRIN indexes for MAX, MIN, ORDER BY? |
Date: | 2015-09-27 21:22:01 |
Message-ID: | CAEepm=1EPWQSOASZ9-pNE5azuKuQyivrXgxuABGO6NgbnjT1yQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 28, 2015 at 9:58 AM, Gavin Wahl <gavinwahl(at)gmail(dot)com> wrote:
> It seems trivial to accelerate a MAX or MIN query with a BRIN index. You
> just find the page range with the largest/smallest value, and then only scan
> that one.
You might need to scan more than that if you don't find any rows that
are visible.
> Would that be hard to implement? I'm interested in working on it
> if someone can give me some pointers.
>
> 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.
Currently you get a Bitmap Index Scan and Bitmap Heap Scan, and then a
Sort node (quicksort or external sort). So the sort is already
receiving data sorted in BRIN-block order, isn't it? Are you saying
that the sort node should switch to something like insertion sort in
this case?
http://www.sorting-algorithms.com/nearly-sorted-initial-order
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2015-09-27 22:15:44 | Re: Building with MinGW |
Previous Message | Alvaro Herrera | 2015-09-27 21:13:06 | Re: BRIN indexes for MAX, MIN, ORDER BY? |