Re: [HACKERS] What I'm working on

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