From: | mlw <markw(at)mohawksoft(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Curt Sampson <cjs(at)cynic(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block size: 8K or 16K? |
Date: | 2002-04-26 12:27:24 |
Message-ID: | 3CC947AC.AB1A68DB@mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2002-04-26 13:16:30 | Re: Vote totals for SET in aborted transaction |
Previous Message | Rod Taylor | 2002-04-26 11:49:42 | Re: pg_constraint |