Re: [HACKERS] Postgres Performance
От | Edwin Ramirez |
---|---|
Тема | Re: [HACKERS] Postgres Performance |
Дата | |
Msg-id | 37D6CFA2.94AA5B38@doc.mssm.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postgres Performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Postgres Performance
|
Список | pgsql-hackers |
If I do a large search the first time is about three times slower than any subsequent overlapping (same data) searches. I would like to always get the higher performance. How are the buffers that I specify to the postmaster used? Will increasing this number improve things? The issue that I am encountering is that no matter how much memory I have on a computer, the performance is not improving. I am willing to fund a project to implement a postgres specific, user configurable cache. Any ideas? -Edwin S. Ramirez- Tom Lane wrote: > > Edwin Ramirez <ramirez@doc.mssm.edu> writes: > > I have a couple of large(?) tables which I would like to keep them in > > memory (cached) so that searches are performed as fast as possible. > > Is it possible to 'pin' the tables and it's indexes in memory? > > If the tables are being touched often, then they will stay in buffer > cache of their own accord. I doubt that pinning them would improve > performance --- if they do get swapped out it'd be because some other > table(s) need to be accessed now, and if you did have these tables > pinned you'd be taking a large hit in access performance for those other > tables because of inadequate buffer space. LRU buffering policy really > works pretty well, so I don't think you need to worry about it. > > > currently I run the postmaster with the following setting: > > postmaster -i -B 2048 -o '-S 2048' > > Are there any other options/values which would yield better performance? > > If you have a reliable OS and power source, consider -o -F (no fsync). > This usually makes for a very substantial performance improvement, and > it can only hurt if your machine goes down without having performed > all the writes the kernel was told to do. > > regards, tom lane > > ************
В списке pgsql-hackers по дате отправления: