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 по дате отправления: