On Wed, Dec 05, 2007 at 01:49:20AM +, Gregory Stark wrote:
> Regardless of what mechanism is used and who is responsible for doing it
> someone is going to have to figure out which blocks are specifically
> interesting to prefetch. Bitmap index scans happen to be the easiest since
> we've alrea
Gregory Stark wrote:
> I could swear this has been discussed in the past too. I seem to recall Luke
> disparaging Postgres on the same basis but proposing an immensely complicated
> solution. posix_fadvise or using libaio in a simplistic fashion as a kind of
> fadvise would be fairly lightweight wa
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> I think this will be easiest to do for bitmap index scans. Since we gather up
> all the pages we'll need before starting the heap scan we can easily skim
> through them, issue posix_fadvises for at least a certain number ahead of the
> actual read poin
"Decibel!" <[EMAIL PROTECTED]> writes:
> On Dec 4, 2007, at 1:42 PM, Gregory Stark wrote:
>> I'm debating between two ways to structure the code right now. Do I put the
>> logic to peek ahead in nodeBitmapHeapScan to read ahead and remember the
>> info
>> seen or in tidbitmap with an new api fun
On Dec 4, 2007, at 1:42 PM, Gregory Stark wrote:
I'm debating between two ways to structure the code right now. Do I
put the
logic to peek ahead in nodeBitmapHeapScan to read ahead and
remember the info
seen or in tidbitmap with an new api function which is only really
useful for
this one u
"Mark Mielke" <[EMAIL PROTECTED]> writes:
> I didn't see exceeded 3X in the graph. But I certainly see 2X+ for most of the
> graphic, and ~3X for very small reads. Possibly, it is avoiding unnecessary
> read-ahead at the drive or OS levels?
Ahh! I think I see how you're misreading it now. You're
"Mark Mielke" <[EMAIL PROTECTED]> writes:
> I didn't see exceeded 3X in the graph. But I certainly see 2X+ for most of the
> graphic, and ~3X for very small reads. Possibly, it is avoiding unnecessary
> read-ahead at the drive or OS levels?
Then you're misreading the graph -- which would be my fa
Gregory Stark wrote:
"Gregory Stark" <[EMAIL PROTECTED]> writes
The two interfaces I'm aware of for this are posix_fadvise() and libaio.
I've run tests with a synthetic benchmark which generates a large file then
reads a random selection of blocks from within it using either synchronous
reads li
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> The two interfaces I'm aware of for this are posix_fadvise() and libaio.
> I've run tests with a synthetic benchmark which generates a large file then
> reads a random selection of blocks from within it using either synchronous
> reads like we do now
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Recently there was a post on -performance about a particular case where
>> Postgres doesn't make very good use of the I/O system. This is when you try
>> to
>> fetch many records spread throughout a table in ran
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Recently there was a post on -performance about a particular case where
>> Postgres doesn't make very good use of the I/O system. This is when you try
>> to
>> fetch many records spread th
Gregory Stark <[EMAIL PROTECTED]> writes:
> Recently there was a post on -performance about a particular case where
> Postgres doesn't make very good use of the I/O system. This is when you try to
> fetch many records spread throughout a table in random order.
> http://archives.postgresql.org/pgsq
"Douglas McNaught" <[EMAIL PROTECTED]> writes:
> On 12/2/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>>
>> The two interfaces I'm aware of for this are posix_fadvise() and libaio. I've
>> run tests with a synthetic benchmark which generates a large file then reads
>> a
>> random selection of blo
On 12/2/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> The two interfaces I'm aware of for this are posix_fadvise() and libaio. I've
> run tests with a synthetic benchmark which generates a large file then reads a
> random selection of blocks from within it using either synchronous reads like
> w
Recently there was a post on -performance about a particular case where
Postgres doesn't make very good use of the I/O system. This is when you try to
fetch many records spread throughout a table in random order.
http://archives.postgresql.org/pgsql-performance/2007-12/msg5.php
Currently Pos
15 matches
Mail list logo
