Re: Postgres 7.3.1 poor insert/update/search performance
От | Bruce Momjian |
---|---|
Тема | Re: Postgres 7.3.1 poor insert/update/search performance |
Дата | |
Msg-id | 200302021039.h12Adah03315@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Postgres 7.3.1 poor insert/update/search performance (Curt Sampson <cjs@cynic.net>) |
Ответы |
Re: Postgres 7.3.1 poor insert/update/search performance
|
Список | pgsql-performance |
Curt Sampson wrote: > > > Some systems, like Solaris, allow you to turn off the > > > disk cache, so the problem may not be one you face.) > > > > I think it would be interesting to investigate disabling the OS' cache > > for all relation I/O (i.e. heap files, index files). That way we could > > both improve performance (by moving all the caching into PostgreSQL's > > domain, where there is more room for optimization)... > > I'm not so sure that there is that all much more room for optimization. > But take a look at what Solaris and FFS do now, and consider how much > work it would be to rewrite it, and then see if you even want to do that > before adding stuff to improve performance. We need free-behind for large sequential scans, like Solaris has. Do we have LRU-2 or LRU-K now? > > If so, is it portable? > > O_DIRECT is not all that portable, I don't think. Certainly not as > portable as mmap. As I remember, DIRECT doesn't return until the data hits the disk (because there is no OS cache), so if you want to write a page so you can reused the buffer, DIRECT would be quite slow. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-performance по дате отправления: