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