Re: PATCH: Using BRIN indexes for sorted output - Mailing list pgsql-hackers

From Greg Stark
Subject Re: PATCH: Using BRIN indexes for sorted output
Date
Msg-id CAM-w4HMirdJ-c4chCZhni_T=9R65z2Zm3Ajg5mBrQ9s6OufZXQ@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: Using BRIN indexes for sorted output  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: PATCH: Using BRIN indexes for sorted output
List pgsql-hackers
Fwiw tuplesort does do something like what you want for the top-k
case. At least it used to last I looked -- not sure if it went out
with the tapesort ...

For top-k it inserts new tuples into the heap data structure and then
pops the top element out of the hash. That keeps a fixed number of
elements in the heap. It's always inserting and removing at the same
time. I don't think it would be very hard to add a tuplesort interface
to access that behaviour.

For something like BRIN you would sort the ranges by minvalue then
insert all the tuples for each range. Before inserting tuples for a
new range you would first pop out all the tuples that are < the
minvalue for the new range.

I'm not sure how you handle degenerate BRIN indexes that behave
terribly. Like, if many BRIN ranges covered the entire key range.
Perhaps there would be a clever way to spill the overflow and switch
to quicksort for the spilled tuples without wasting lots of work
already done and without being too inefficient.



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: [DOCS] Stats views and functions not in order?
Next
From: Tom Lane
Date:
Subject: Re: Making Vars outer-join aware