Re: [HACKERS] \dt and disk access
| От | Bruce Momjian |
|---|---|
| Тема | Re: [HACKERS] \dt and disk access |
| Дата | |
| Msg-id | 8e5c96029d0d0b723e3e3e75ebc9c293 обсуждение исходный текст |
| Ответ на | [HACKERS] \dt and disk access (Bruce Momjian <maillist@candle.pha.pa.us>) |
| Список | pgsql-hackers |
> 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? :( palloc() basically malloc's from a pool that gets auto-free'd at the end of statements or transcations. We could us mmap(), but why bother if we can just malloc() all the memory we need? That is what has me confused. Anyone know an advantage to using mmap() when you really don't want the image on disk? I would suspect that mmap() would use the file system for backing store for the memory rather than swap. But the thrashing of large sorts is going to be as big a problem with this as with malloc'ed memory backing store in SWAP, in fact slower because swap backing store is faster than file system backing store, so we might was well use psort() for those large cases. psort() does its sorts in pieces with merging, and doesn't load large amount of data into memory at once, so it doesn't thrash. It uses disk files to store itermediate sorts, hence the large startup time. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
В списке pgsql-hackers по дате отправления: