Re: GSoC 2011: Fast GiST index build

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: GSoC 2011: Fast GiST index build
Дата
Msg-id 4DB7C563.9060605@enterprisedb.com
обсуждение исходный текст
Ответ на Re: GSoC 2011: Fast GiST index build  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: GSoC 2011: Fast GiST index build  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
On 27.04.2011 09:51, Alexander Korotkov wrote:
> On Tue, Apr 26, 2011 at 1:10 PM, Alexander Korotkov<aekorotkov@gmail.com>wrote:
>
>> Since algorithm is focused to reduce I/O, we should expect best
>> acceleration in the case when index doesn't fitting to memory. Size of
>> buffers is comparable to size of whole index. It means that if we can hold
>> buffers in memory then we mostly can hold whole index in memory. That's why
>> I think we should have simple on-disk buffers management for first
>> representative benchmark.
>>
> Since we need to free all buffers after index built, I believe that buffers
> should be stored separately. If not, index become bloat immediatly after
> creation. We probably need to create a temporary relation to store buffers
> in it. If my thought is right, then is there any example of using temporary
> relation?

A temporary relation is a bit heavy-weight for this, a temporary file 
should be enough. See src/backend/storage/file/buffile.c, 
BufFileCreateTemp() function in particular. Or perhaps a tuplestore 
suits better, see src/backend/utils/sort/tuplestore.c, that's simpler to 
use if you're storing tuples. tuplestore only supports storing heap 
tuples at the moment, but it could easily be extended to store index 
tuples, like tuplesort.c does.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Markus Wanner
Дата:
Сообщение: Re: Proposal - asynchronous functions
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Memory leak in FDW