| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2013-01-17 02:44:53 | Re: Parallel query execution |
| Previous Message | Simon Riggs | 2013-01-17 01:45:00 | Re: log_lock_waits to identify transaction's relation |