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:mar...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers