On Sun, 23 Aug 1998, Bruce Momjian wrote:
> >
> > Oh...I like this :) that would give us something that the "big
> > guys" don't also, no? Bruce?
> >
> > Can someone clarify something for me? If, for example, we have
> > the blocksize set to 16k, but the file system size is 8k, would the OS do
> > both reads at the same time in order to get the full 16k? I hope someone
> > can follow this through (unless I'm actually clear), but if we left the
> > tuples size at 8k fixed, and had that 16k tuple span two rows, do we send
> > a request to the OS for the one block, then, once we get that back,
> > determine that we need the next and request that?
>
> The filesystem block size really controls how fine-graned the file block
> allocation is. It keeps 8k blocks as one contigious chunk on the disk
> (ignoring trailing file fragments which are blocksize/8 in size).
>
> How the OS does the disk requests is different. It is related to the
> base size of a disk block(usually 512 bytes), and if multiple requests
> can be sent to the drive at the same time(tagged queuing?). These are
> really not related to the filesystem block size, except that larger
> block sizes are made up of larger contigious disk block groups.
Okay...but, what I was more trying to get at was that, ignoring
the operating system level right now, a 16k tuple that has to span two 8k
'rows' is going to require:
1 read for the first half
processing to determine that a second half is required
1 read for the second half
A 16k that spans a single 16k row will require:
1 read for the whole thing
considering all the streamlining that you've been working at, it
seems illogical to advocate a two read system only, when we can have a two
read system that gives us a base solution, with a one read system for
those that wish to reduce that overhead...no?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
