On Thu, 25 Apr 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > 1. Theoretical proof: two components of the delay in retrieving a
> > block from disk are the disk arm movement and the wait for the
> > right block to rotate under the head.
>
> > When retrieving, say, eight adja
Nice test. Would you test simultaneous 'dd' on the same file, perhaps
with a slight delay between to the two so they don't read each other's
blocks?
seek() in the file will turn off read-ahead in most OS's. I am not
saying this is a major issue for PostgreSQL but the numbers would be
interesti
Tom Lane wrote:
> ...
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > 3. Proof by testing. I wrote a little ruby program to seek to a
> > random point in the first 2 GB of my raw disk partition and read
> > 1-8 8K blocks of data. (This was done as one I/O request.) (Using
> > the raw disk partition
On Thu, 2002-04-25 at 12:47, Curt Sampson wrote:
> On Thu, 25 Apr 2002, Lincoln Yeoh wrote:
>
> > I think the raw partitions will be more trouble than they are worth.
> > Reading larger chunks at appropriate circumstances seems to be the "low
> > hanging fruit".
>
> That's certainly a good start
Curt Sampson wrote:
> 3. Proof by testing. I wrote a little ruby program to seek to a
> random point in the first 2 GB of my raw disk partition and read
> 1-8 8K blocks of data. (This was done as one I/O request.) (Using
> the raw disk partition I avoid any filesystem buffering.) Here are
> typica
Curt Sampson <[EMAIL PROTECTED]> writes:
> 1. Theoretical proof: two components of the delay in retrieving a
> block from disk are the disk arm movement and the wait for the
> right block to rotate under the head.
> When retrieving, say, eight adjacent blocks, these will be spread
> across no mor
On Thu, 25 Apr 2002, Lincoln Yeoh wrote:
> I think the raw partitions will be more trouble than they are worth.
> Reading larger chunks at appropriate circumstances seems to be the "low
> hanging fruit".
That's certainly a good start. I don't know if the raw partitions
would be more trouble than
On Thu, 25 Apr 2002, Curt Sampson wrote:
> Here's the ratio table again, with another column comparing the
> aggregate number of requests per second for one process and four
> processes:
>
Just for interest, I ran this again with 20 processes working
simultaneously. I did six runs at each blockr
At 12:19 PM 4/25/02 +0900, Curt Sampson wrote:
>Grabbing bigger chunks is always optimal, AFICT, if they're not
>*too* big and you use the data. A single 64K read takes very little
>longer than a single 8K read.
Yes I agree that if sequential scans are done reading ahead helps.
And often doesn't
On Thu, 25 Apr 2002, Bruce Momjian wrote:
> Well, we are guilty of trying to push as much as possible on to other
> software. We do this for portability reasons, and because we think our
> time is best spent dealing with db issues, not issues then can be deal
> with by other existing software, a
On Wed, 24 Apr 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Grabbing bigger chunks is always optimal, AFICT, if they're not
> > *too* big and you use the data. A single 64K read takes very little
> > longer than a single 8K read.
>
> Proof?
Well, there are various sorts o
Tom Lane wrote:
>Curt Sampson <[EMAIL PROTECTED]> writes:
>
>>Grabbing bigger chunks is always optimal, AFICT, if they're not
>>*too* big and you use the data. A single 64K read takes very little
>>longer than a single 8K read.
>>
>
>Proof?
>
I contend this statement.
It's optimal to a point.
Well, this is a very interesting email. Let me comment on some points.
---
Curt Sampson wrote:
> On Wed, 24 Apr 2002, Bruce Momjian wrote:
>
> > > 1. Not all systems do readahead.
> >
> > If they don't, that isn't ou
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Grabbing bigger chunks is always optimal, AFICT, if they're not
> > *too* big and you use the data. A single 64K read takes very little
> > longer than a single 8K read.
>
> Proof?
Long time ago I tested with the 32k block size and got 1.5-2x speed
Curt Sampson <[EMAIL PROTECTED]> writes:
> Grabbing bigger chunks is always optimal, AFICT, if they're not
> *too* big and you use the data. A single 64K read takes very little
> longer than a single 8K read.
Proof?
regards, tom lane
---(end of br
On Wed, 24 Apr 2002, Bruce Momjian wrote:
> > 1. Not all systems do readahead.
>
> If they don't, that isn't our problem. We expect it to be there, and if
> it isn't, the vendor/kernel is at fault.
It is your problem when another database kicks Postgres' ass
performance-wise.
And at that p
Curt Sampson wrote:
> On Wed, 24 Apr 2002, Bruce Momjian wrote:
>
> > We expect the file system to do re-aheads during a sequential scan.
> > This will not happen if someone else is also reading buffers from that
> > table in another place.
>
> Right. The essential difficulties are, as I see it:
On Wed, 24 Apr 2002, Bruce Momjian wrote:
> We expect the file system to do re-aheads during a sequential scan.
> This will not happen if someone else is also reading buffers from that
> table in another place.
Right. The essential difficulties are, as I see it:
1. Not all systems do readah
Curt Sampson wrote:
> At 12:41 PM 4/23/02 -0400, Bruce Momjian wrote:
>
> >This is an interesting point, that an index scan may fit in the cache
> >while a sequential scan may not.
>
> If so, I would expect that the number of pages read is significantly
> smaller than it was with a sequential sc
At 12:41 PM 4/23/02 -0400, Bruce Momjian wrote:
>This is an interesting point, that an index scan may fit in the cache
>while a sequential scan may not.
If so, I would expect that the number of pages read is significantly
smaller than it was with a sequential scan. If that's the case,
doesn't th
20 matches
Mail list logo
