From: James Mansion <james@mansionfamily.plus.com>
To: matthew@flymine.org
Cc: pgsql-performance@postgresql.org
Subject: Re: RAID arrays and performance
Date: Tue, 04 Dec 2007 15:50:12 +0000
Message-ID: <47557734.7090604@mansionfamily.plus.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0712041454110.3731@aragorn.flymine.org>
References: <Pine.LNX.4.58.0712041213490.3731@aragorn.flymine.org>
<87lk8aiqf3.fsf@oxford.xeocode.com>
<Pine.LNX.4.58.0712041247540.3731@aragorn.flymine.org>
<475559F4.7060104@mark.mielke.cc>
<Pine.LNX.4.58.0712041349380.3731@aragorn.flymine.org>
<4755648C.90905@mark.mielke.cc>
<Pine.LNX.4.58.0712041454110.3731@aragorn.flymine.org>
matthew@flymine.org wrote:
> So, if you hand requests one by one to the disc, it will almost always be
> faster to order them. On the other hand, if you hand a huge long list of
> requests to a decent SCSI or SATA-NCQ disc in one go, it will reorder the
> reads itself, and it will do it much better than you.
>
>
Sure - but this doesn't suggest threading so much as pushing all reads
into AIO as soon as they can
be identified - and hoping that your os has a decent AIO subsystem,
which is sadly a tall order
for many *nix systems.
I do think some thought should be given to threading but I would expect
the effect to be more
noticeable for updates where you update tables that have multiple
indices. In the case of your
scan then you need threading on CPU (rather than concurrent IO through
AIO) if the disks
can feed you data faster than you can scan it. Which might be the case
for some scans
using user functions, but I wouldn't have thought it would be the case
for a sinple index scan.
At some point, hopefully, the engines will be:
a) thread safe (if not thread hot) so it can exist with threaded user
functions and embedded
languages
b) able to incorporate C++ add-in functionality
There may not be a pressing reason to support either of these, but
having a capability to
experiment would surely be helpful and allow incremental enhancement -
so baby steps
could be made to (for example) move stats and logging to a background
thread, move
push of results to clients out of the query evaluator thread, and so
on. Parallel threading
queries is a whle different ball game which needs thought in the optimiser.
James
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: james@mansionfamily.plus.com, matthew@flymine.org
Subject: Re: RAID arrays and performance
In-Reply-To: <47557734.7090604@mansionfamily.plus.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