From: Markus Schaber <schabi@logix-tt.com>
To: pgsql-performance@postgresql.org
Subject: Re: Large tables (was: RAID 0 not as fast as
Date: Wed, 20 Sep 2006 20:02:06 +0200
Message-ID: <4511821E.2030902@logix-tt.com> (raw)
In-Reply-To: <C136C28E.4E9%llonergan@greenplum.com>
References: <C136C28E.4E9%llonergan@greenplum.com>
Hi, Luke,
Luke Lonergan wrote:
>> Do you think that adding some posix_fadvise() calls to the backend to
>> pre-fetch some blocks into the OS cache asynchroneously could improve
>> that situation?
>
> Nope - this requires true multi-threading of the I/O, there need to be
> multiple seek operations running simultaneously. The current executor
> blocks on each page request, waiting for the I/O to happen before requesting
> the next page. The OS can't predict what random page is to be requested
> next.
I thought that posix_fadvise() with POSIX_FADV_WILLNEED was exactly
meant for this purpose?
My idea was that the executor could posix_fadvise() the blocks it will
need in the near future, and later, when it actually issues the blocking
read, the block is there already. This could even give speedups in the
single-spindle case, as the I/O scheduler could already fetch the next
blocks while the executor processes the current one.
But there must be some details in the executor that prevent this.
> We can implement multiple scanners (already present in MPP), or we could
> implement AIO and fire off a number of simultaneous I/O requests for
> fulfillment.
AIO is much more intrusive to implement, so I'd preferrably look
whether posix_fadvise() could improve the situation.
Thanks,
Markus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: schabi@logix-tt.com
Subject: Re: Large tables (was: RAID 0 not as fast as
In-Reply-To: <4511821E.2030902@logix-tt.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox