Re: How Postgresql Compares For Query And Load Operations
От | Tom Lane |
---|---|
Тема | Re: How Postgresql Compares For Query And Load Operations |
Дата | |
Msg-id | 3894.995646092@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: How Postgresql Compares For Query And Load Operations (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-general |
Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Hm. The theory about simple sequential reads is that we expect the >> kernel to optimize the disk access, since it'll recognize that we are >> doing sequential access to the table file and do read-aheads. Or that's >> the theory, anyway. > If it is Linux, they turn off read-ahead on the first fseek() and it > never gets turned on again, or so I am told. And because we have > virtual file descriptors, that table remains open after random access > and the readahead bit doesn't get set for the next sequential scan. Ugh. And even if we hacked the VFD code to close/reopen the file, the shared disk buffers might still have some entries for some blocks of the file, causing those blocks not to be requested during the seq scan, thus disabling read-ahead again. It sounds like we really ought to try to get this Linux behavior fixed to work more like BSD (ie, some reasonably small number of consecutive reads turns on read-ahead). Red Hat guys, are you listening? regards, tom lane
В списке pgsql-general по дате отправления: