Re: Proposal of PITR performance improvement for 8.4.
От | Heikki Linnakangas |
---|---|
Тема | Re: Proposal of PITR performance improvement for 8.4. |
Дата | |
Msg-id | 49070949.4070404@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Proposal of PITR performance improvement for 8.4. (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-hackers |
Gregory Stark wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > >> I'm happy with the idea of a readahead process. I thought we were >> implementing a BackgroundReader process for other uses. Is that dead >> now? > > You and Bruce seem to keep resurrecting that idea. I've never liked it -- I > always hated that in Oracle and thought it was a terrible kludge. > > I think the inter-process communication would be way too heavy-weight, by the > time the other process is schedule the process which needed the blocks would > have probably have done many of them already anyways. Worse, you would need a > large number of reading processes and would start to run into locking > contention on the work-queue as well. > > In any case it would be a lot of code to do what posix_fadvise does for us > with a simple syscall anyways. I agree. > Am I misjudging this? Is this a popular idea? We could always implement it as > a fall-back implementation for mdprefetch() where posix_fadvise (and libaio > assuming we implement that as well) don't work. It has the advantage of > working with any system at all even if it predates 1003.1. Yeah, if we want to support prefetching on systems that don't have posix_fadvise(), that would be the way to do it. posix_fadvise() is a good API. We can support multiple platform-specific implementations of it if there's interest, using posix_fadvise(), aio to a dummy buffer, whatever functions there's on Windows, or background reader processes or threads. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: