Well, to check if there is a real potential gain all we need is a
small comparing test using PgSQL compiled with LOG block size equal to
say 1K and direct IO enabled.
Rgds,
-Dimitri
> On Fri, Mar 30, 2007 at 04:25:16PM +0200, Dimitri wrote:
> > The problem is while your goal is to commit as fast as possible - it's
> > pity to vast I/O operation speed just keeping common block size...
> > Let's say if your transaction modification entering into 512K - you'll
> > be able to write much more 512K blocks per second rather 8K per second
> > (for the same amount of data)... Even we rewrite probably several
> > times the same block with incoming transactions - it still costs on
> > traffic, and we will process slower even H/W can do better. Don't
> > think it's good, no? ;)
> >
> > Rgds,
> > -Dimitri
> >
> With block sizes you are always trading off overhead versus space
> efficiency. Most OS write only in 4k/8k to the underlying hardware
> regardless of the size of the write you issue. Issuing 16 512byte
> writes has much more overhead than 1 8k write. On the light transaction
> end, there is no real benefit to a small write and it will slow
> performance for high throughput environments. It would be better to,
> and I think that someone is looking into, batching I/O.
>
> Ken
>
