Guys,
Single core CPU's are dying for Home users, my cellular has 4 cores.
Today's standard is minimum 4 cores per CPU and tomorrow who knows?
Parallelization sometimes is only one solution for heavy nightly jobs.
From the other hand parallelization is very tricky and unpredictable
when it comes into user's hands. Anyway when you have this option (same
for hash partitioning) you in much better position than you don't have
it. The question is: when we may hope to have it?
Sincerely yours,
Yuri Levinsky, DBA
Celltick Technologies Ltd., 32 Maskit St., Herzliya 46733, Israel
Mobile: +972 54 6107703, Office: +972 9 9710239; Fax: +972 9 9710222
-----Original Message-----
From: Markus Wanner [mailto:markus@bluegap.ch]
Sent: Wednesday, June 26, 2013 6:56 PM
To: Heikki Linnakangas
Cc: Kevin Grittner; Claudio Freire; Robert Haas; Bruce Momjian; Yuri
Levinsky; PostgreSQL-Dev
Subject: Re: [HACKERS] Hash partitioning.
On 06/26/2013 05:46 PM, Heikki Linnakangas wrote:
> We could also allow a large query to search a single table in
parallel.
> A seqscan would be easy to divide into N equally-sized parts that can
> be scanned in parallel. It's more difficult for index scans, but even
> then it might be possible at least in some limited cases.
So far reading sequentially is still faster than hopping between
different locations. Purely from the I/O perspective, that is.
For queries where the single CPU core turns into a bottle-neck and which
we want to parallelize, we should ideally still do a normal, fully
sequential scan and only fan out after the scan and distribute the
incoming pages (or even tuples) to the multiple cores to process.
Regards
Markus Wanner
This mail was received via Mail-SeCure System.