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
On 29 September 2015 at 13:20, Jeremy Harris 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.
Hi Gavin
Note that Alexander Korotkov already started work in 2013 on a
somewhat similar feature called partial sort:
http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com
In particular, see the 2nd patch for KNN sort -- it uses known
bounding
On 09/28/2015 05:28 PM, Marti Raudsepp wrote:
Note that Alexander Korotkov already started work in 2013 on a
somewhat similar feature called partial sort:
http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com
In particular, see the 2nd patch for
Alvaro Herrera writes:
> Gavin Wahl 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. Would that be hard to implement? I'm interested in working
Gavin Wahl 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. Would that be hard to implement? I'm interested in working
> on it if someone can give me some pointers.
I think
On Mon, Sep 28, 2015 at 9:58 AM, Gavin Wahl 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
> Yeah. I would urgently recommend that people *not* try to build new
> things like planagg.c right now. A large part of the point of upper
> planner path-ification is to have a less grotty way of dealing with
> things like specialized aggregate implementations.
Ok. I will wait and ask again