adding new pages bulky way

Поиск
Список
Период
Сортировка
От Victor Y. Yegorov
Тема adding new pages bulky way
Дата
Msg-id 20050606195904.GA9502@mits.lv
обсуждение исходный текст
Ответы Re: adding new pages bulky way  (Alvaro Herrera <alvherre@surnet.cl>)
Re: adding new pages bulky way  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I need your advice.

For on-disk bitmap I run a list of TIDs.

TIDs are stored in pages as an array, page's opaque data holds an array of
bits, indicating whether corresponding TID has been deleted and should be
skipped during the scan.

Pages, that contain TIDs list, are organized in extents, each extent has 2^N
pages, where N is extent's number (i.e. 2nd extent will occupy 4 pages).
Given that I know number of TIDs, that fit into one page, and the TID's
sequential number, I can easily calculate:
-  extent number TID belongs to;
-  page offset inside that extent, and;
-  TID place in the page.

At the moment, I store BlockNumber of the extent's first page in the
metapage and allocate all pages that belongs to that extent sequentially. I
need to do so to minimize number of page reads when searching for the TID in
the list; I'll need to read 1 page at most to find out TID at given position
during the scan. I hope you understood the idea.

This also means, that while extent's pages are being added this way, no other
pages can be added to the index. And the higher is extent's number, the more
time it'll take to allocate all pages.

The question is: allocating pages this way is really ugly, I understand. Is
there some API that would allow allocating N pages in the bulk way?
Maybe this is a know problem, that has been already solved before?
Any other ideas?


Thanks in advance!


-- 

Victor Y. Yegorov


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] regexp_replace
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Suggestion: additional system views