Skip site navigation (1) Skip section navigation (2)

Re: Parallel query execution

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel query execution
Date: 2013-01-17 02:42:04
Message-ID: CAGTBQpY_iw4-ouQdjg_Gkqkr1-L7aF1Gz-EBT4=FHbrww5W6qg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Jan 16, 2013 at 10:04 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> Hmm...
>>
>> How about being aware of multiple spindles - so if the requested data
>> covers multiple spindles, then data could be extracted in parallel.  This
>> may, or may not, involve multiple I/O channels?
>
>
>
> effective_io_concurrency does this for bitmap scans.  I thought there was a
> patch in the commitfest to extend this to ordinary index scans, but now I
> can't find it.

I never pushed it to the CF since it interacts so badly with the
kernel. I was thinking about pushing the small part that is a net win
in all cases, the back-sequential patch, but that's independent of any
spindle count. It's more related to rotating media and read request
merges than it is to multiple spindles or parallelization.

The kernel guys basically are waiting for me to patch the kernel. I
think I convinced our IT guy at the office to lend me a machine for
tests... so it might happen soon.


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2013-01-17 02:44:53
Subject: Re: Parallel query execution
Previous:From: Simon RiggsDate: 2013-01-17 01:45:00
Subject: Re: log_lock_waits to identify transaction's relation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group