Re: BRIN indexes for MAX, MIN, ORDER BY?
От | Tom Lane |
---|---|
Тема | Re: BRIN indexes for MAX, MIN, ORDER BY? |
Дата | |
Msg-id | 11881.1443393360@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BRIN indexes for MAX, MIN, ORDER BY? (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BRIN indexes for MAX, MIN, ORDER BY?
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@2ndquadrant.com> 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 >> on it if someone can give me some pointers. > I think this means you need to represent this operation as a specific > Path in some way. See build_minmax_path() and its callers in planagg; > you probably need to tweak preprocess_minmax_aggregates() to consider > this. > This doesn't look like a simple project to me, mind. >> 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. > I wouldn't know where to start for this. Maybe once Tom is done with > planner rejiggering it would make sense to consider looking at how to do > it. 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. (And yes, I am working on that. Honest.) regards, tom lane
В списке pgsql-hackers по дате отправления: