Re: Block size: 8K or 16K?
От | mlw |
---|---|
Тема | Re: Block size: 8K or 16K? |
Дата | |
Msg-id | 3CC947AC.AB1A68DB@mohawksoft.com обсуждение исходный текст |
Ответ на | Re: Block size: 8K or 16K? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
Bruce Momjian wrote: > > Curt Sampson wrote: > > On Thu, 25 Apr 2002, mlw wrote: > > > > > ...but my gut tells me that using 16K blocks will increase performance > > > over 8K. Aleady I have seen a sequential scan of a large table go from 20 > > > seconds using 8K to 17.3 seconds using 16K. > > > > You should be able to get the same performance increase with 8K > > blocks by reading two blocks at a time while doing sequential scans. > > That's why I've been promoting this idea of changing postgres to > > do its own read-ahead. > > > > Of course, Bruce might be right that the OS read-ahead may take > > care of this anyway, but then why would switching to 16K blocks > > improve sequential scans? Possibly because I'm missing something here. > > I am almost sure that increasing the block size or doing read-ahead in > the db will only improve performance if someone is performing seeks in > the file at the same time, and hence OS readahead is being turned off. I largely agree with you, however, don't underestimate the overhead of a read() call. By doubling the block size, the overhead of my full table scan was cut in half, thus potentially more efficient, 20 seconds was reduced to 17. (That was on a machine only doing one query, not one under full load, so the real effect may be much more subtle.) In fact, I posted some results of a comparison between 16k and 8k blocks, I saw very little difference on most tests while a couple looked pretty interesting.
В списке pgsql-hackers по дате отправления: