Re: Postgres 7.3.1 poor insert/update/search performance
От | Neil Conway |
---|---|
Тема | Re: Postgres 7.3.1 poor insert/update/search performance |
Дата | |
Msg-id | 1043968734.3123.27.camel@tokyo обсуждение исходный текст |
Ответ на | Re: Postgres 7.3.1 poor insert/update/search performance (Andrew Sullivan <andrew@libertyrms.info>) |
Ответы |
Re: Postgres 7.3.1 poor insert/update/search performance
|
Список | pgsql-performance |
On Wed, 2003-01-22 at 07:05, Andrew Sullivan wrote: > (As you point out, this caclulation is complicated by the potential to > waste memory by caching the data twice If we had a good buffer replacement algorithm (which we currently do not), ISTM that hot pages retained in PostgreSQL's buffer cache would never get loaded from the OS's IO cache, thus causing those pages to eventually be evicted from the OS's cache. So the "cache the data twice" problem doesn't apply in all circumstances. > 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), as well as make configuration simpler: in an ideal world, it would remove the need to consider the OS' caching when configuring the amount of shared memory to allocate to PostgreSQL. Can this be done using O_DIRECT? If so, is it portable? BTW, if anyone has any information on actually *using* O_DIRECT, I'd be interested in it. I tried to quickly hack PostgreSQL to use it, without success... Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
В списке pgsql-performance по дате отправления: