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
On 3/30/07, Erik Jones <erik@myemma.com> wrote:
>
> On Mar 30, 2007, at 8:14 AM, Dimitri wrote:
>
> >>
> >> You are right in that the page size constraint is lifted in that
> >> directio cuts out the VM filesystem cache. However, the Solaris
> >> kernel still issues io ops in terms of its logical block size (which
> >> we have at the default 8K). It can issue io ops for fragments as
> >> small as 1/8th of the block size, but Postgres issues its io requests
> >> in terms of the block size which means that io ops from Postgres will
> >> be in 8K chunks which is exactly what we see when we look at our
> >> system io stats. In fact, if any io request is made that isn't a
> >> multiple of 512 bytes (the disk sector size), the file system
> >> switches back to the buffered io.
> >
> > Oh, yes, of course! yes, you still need to respect multiple of 512
> > bytes block size on read and write - sorry, I was tired :)
> >
> > Then it's seems to be true - default XLOG block size is 8K, means for
> > every even small auto-committed transaction we should write 8K?... Is
> > there any reason to use so big default block size?...
> >
> > Probably it may be a good idea to put it as 'initdb' parameter? and
> > have such value per database server?
>
> I believe it's because that is a pretty normal Unix kernal block size
> and you want the two to match.
>
> erik jones <erik@myemma.com>
> software developer
> 615-296-0838
> emma(r)
>
>
>
>
