1. My understanding is that the parallel query stuff they want to add into the core of postgres is about introducing parallel algorithms for scans, sorts, etc. The advantage is that when it is working there will be an opportunity to help everyone, a) regardless of how you use postgres (psql, API, etc) and b) transparently from the user perspective.
2. par_psql on the other hand is two things. Mainly it's a cute piece of syntactic sugar for psql users that makes it trivial to run multiple queries in parallel (as you observe) but also synchronises them automatically as they end, which is important.
I've also provided some guides about how to use this feature to substantially accelerate single queries without much work or refactoring. It's generally a good tool for SQL workflows that might otherwise be managed by a combination of BASH and SQL, or for situations where you have one epic-sized query that is naturally easy to parallelise.
This talk I gave at FOSS4G Europe (a GIS conference) offers some hints about identifying situations where queries or workflows are trivially decomposable into parallel small queries, allowing a huge speedup:
"Unfortunately, due to the technical challenges being more difficult than expected by the team led by EnterpriseDB programmer Robert Haas, no parallel query features have yet been committed."
====
"If you use '--will-cite' in scripts you are expected to pay\n", "the 10000 EUR, because you are making it harder to see the\n", "citation notice.
====
This would be quite funny if it had not been attempted seriously in a major Gnu project already!
Check out the SHAMELESS Ole Tange and his bizarre attempts to simultaneously force people to obey academic citations while at the same offering you the chance to throw the academic process in the bin for a mere 10000 EUR payment to him.
I wish I was joking. GNU Nagware! It literally nags you with a warning message every time you use it until you tell it you agree to cite him or pay him 10000 EUR.
I have no idea how the Gnu foundation allows this!
sub bibtex {
# Returns: N/A
print join("\n",
"Academic tradition requires you to cite works you base your article on.",
"When using programs that use GNU Parallel to process data for publication",
"please cite:",
"",
"\@article{Tange2011a,",
" title = {GNU Parallel - The Command-Line Power Tool},",
" author = {O. Tange},",
" address = {Frederiksberg, Denmark},",
" journal = {;login: The USENIX Magazine},",
" month = {Feb},",
" number = {1},",
" volume = {36},",
" url = {http://www.gnu.org/s/parallel},",
" year = {2011},",
" pages = {42-47}",
" doi = {10.5281/zenodo.16303}",
"}",
"",
"(Feel free to use \\nocite{Tange2011a})",
"",
"This helps funding further development; and it won't cost you a cent.",
"If you pay 10000 EUR you should feel free to use GNU Parallel without citing.",
"",
"If you send a copy of your published article to tange\@gnu.org, it will be",
"mentioned in the release notes of next version of GNU Parallel.\n\n",
);
while(not -e $ENV{'HOME'}."/.parallel/will-cite") {
print "\nType: 'will cite' and press enter.\n> ";
my $input = <STDIN>;
if($input =~ /will cite/i) {
mkdir $ENV{'HOME'}."/.parallel";
if(open (my $fh, ">", $ENV{'HOME'}."/.parallel/will-cite")) {
close $fh;
print "\nThank you for your support. It is much appreciated. The citation\n",
"notice is now silenced. You may also use '--will-cite'.\n",
"If you use '--will-cite' in scripts you are expected to pay\n",
"the 10000 EUR, because you are making it harder to see the\n",
"citation notice.\n\n";
Yes, but there's a little more to it.
1. My understanding is that the parallel query stuff they want to add into the core of postgres is about introducing parallel algorithms for scans, sorts, etc. The advantage is that when it is working there will be an opportunity to help everyone, a) regardless of how you use postgres (psql, API, etc) and b) transparently from the user perspective.
2. par_psql on the other hand is two things. Mainly it's a cute piece of syntactic sugar for psql users that makes it trivial to run multiple queries in parallel (as you observe) but also synchronises them automatically as they end, which is important.
I've also provided some guides about how to use this feature to substantially accelerate single queries without much work or refactoring. It's generally a good tool for SQL workflows that might otherwise be managed by a combination of BASH and SQL, or for situations where you have one epic-sized query that is naturally easy to parallelise.
This talk I gave at FOSS4G Europe (a GIS conference) offers some hints about identifying situations where queries or workflows are trivially decomposable into parallel small queries, allowing a huge speedup:
http://graemebell.net/foss4gcomo.pdf
Hope this is of interest and use to you.