Re: [HACKERS] \dt and disk access

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: [HACKERS] \dt and disk access
Дата
Msg-id 4fc1cfa700e1c3739a66c656eb570cfa
обсуждение исходный текст
Ответ на [HACKERS] \dt and disk access  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
On Sun, 22 Jun 1997, Bruce Momjian wrote:

> >     Why use shared memory for this?  Why not use mmap() for it?  Come
> > to think of it, mmap()'ng it would have better scalability, no?  If you
> > already know the result size (ie. 256k), you could that have the code try
> > to mmap() that amount of memory to do the sort in.  If the mmap() fails,
> > revert to using a file...now the result size of the SELECT doesn't have a
> > compiled in "limit" to the size of memory used for the sort...its restricted
> > to the amount of memory on the machine (ie. if I double the RAM, I should be
> > able to have double the results sorted in memory instead of one disk)
>
> I don't think we need mmap() because we never need to put it on disk.
> Just palloc() the memory.

    okay, I'm not totally familiary with palloc()...I did a project while
back where we mmap()'d a region of memory so that we didn't need to write
to disk.  Essentially, I used ftruncate() to create the size of the buffer I
wanted to mmap(), and never flushed the memory...

    Not sure what palloc() does though...should look into it, eh? :(

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

------------------------------

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