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.
