Re: PATCH: Using BRIN indexes for sorted output

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: PATCH: Using BRIN indexes for sorted output
Дата
Msg-id CAM-w4HMirdJ-c4chCZhni_T=9R65z2Zm3Ajg5mBrQ9s6OufZXQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PATCH: Using BRIN indexes for sorted output  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: PATCH: Using BRIN indexes for sorted output  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: [DOCS] Stats views and functions not in order?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Making Vars outer-join aware