11 Commits (16be2fd100199bdf284becfcee02c5eb20d8a11d)

Author	SHA1	Message	Date
Robert Haas	5262f7a4fc	Add optimizer and executor support for parallel index scans. ... In combination with 569174f1be, which taught the btree AM how to perform parallel index scans, this allows parallel index scan plans on btree indexes. This infrastructure should be general enough to support parallel index scans for other index AMs as well, if someone updates them to support parallel scans. Amit Kapila, reviewed and tested by Anastasia Lubennikova, Tushar Ahuja, and Haribabu Kommi, and me.	9 years ago
Robert Haas	51ee6f3160	Replace min_parallel_relation_size with two new GUCs. ... When min_parallel_relation_size was added, the only supported type of parallel scan was a parallel sequential scan, but there are pending patches for parallel index scan, parallel index-only scan, and parallel bitmap heap scan. Those patches introduce two new types of complications: first, what's relevant is not really the total size of the relation but the portion of it that we will scan; and second, index pages and heap pages shouldn't necessarily be treated in exactly the same way. Typically, the number of index pages will be quite small, but that doesn't necessarily mean that a parallel index scan can't pay off. Therefore, we introduce min_parallel_table_scan_size, which works out a degree of parallelism for scans based on the number of table pages that will be scanned (and which is therefore equivalent to min_parallel_relation_size for parallel sequential scans) and also min_parallel_index_scan_size which can be used to work out a degree of parallelism based on the number of index pages that will be scanned. Amit Kapila and Robert Haas Discussion: http://postgr.es/m/CAA4eK1KowGSYYVpd2qPpaPPA5R90r++QwDFbrRECTE9H_HvpOg@mail.gmail.com Discussion: http://postgr.es/m/CAA4eK1+TnM4pXQbvn7OXqam+k_HZqb0ROZUMxOiL6DWJYCyYow@mail.gmail.com	9 years ago
Robert Haas	5e6d8d2bbb	Allow parallel workers to execute subplans. ... This doesn't do anything to make Param nodes anything other than parallel-restricted, so this only helps with uncorrelated subplans, and it's not necessarily very cheap because each worker will run the subplan separately (just as a Hash Join will build a separate copy of the hash table in each participating process), but it's a first step toward supporting cases that are more likely to help in practice, and is occasionally useful on its own. Amit Kapila, reviewed and tested by Rafia Sabih, Dilip Kumar, and me. Discussion: http://postgr.es/m/CAA4eK1+e8Z45D2n+rnDMDYsVEb5iW7jqaCH_tvPMYau=1Rru9w@mail.gmail.com	9 years ago
Peter Eisentraut	f9472d7256	Run select_parallel test by itself ... Remove the plpgsql wrapping that hides the context. So now the test will fail if the work doesn't actually happen in a parallel worker. Run the test in its own test group to ensure it won't run out of resources for that.	9 years ago
Tom Lane	598aa194af	Still another try at fixing scanjoin_target insertion into parallel plans. ... The previous code neglected the fact that the scanjoin_target might carry sortgroupref labelings that we need to absorb. Instead, do create_projection_path() unconditionally, and tweak the path's cost estimate after the fact. (I'm now convinced that we ought to refactor the way we account for sometimes not needing a separate projection step, but right now is not the time for that sort of cleanup.) Problem identified by Amit Kapila, patch by me.	10 years ago
Robert Haas	54f5c5150f	Try again to fix the way the scanjoin_target is used with partial paths. ... Commit 04ae11f62e removed some broken code to apply the scan/join target to partial paths, but its theory that this processing step is totally unnecessary turns out to be wrong. Put similar code back again, but this time, check for parallel-safety and avoid in-place modifications to paths that may already have been used as part of some other path. (This is not an entirely elegant solution to this problem; it might be better, for example, to postpone generate_gather_paths for the topmost scan/join rel until after the scan/join target has been applied. But this is not the time for such redesign work.) Amit Kapila and Robert Haas	10 years ago
Robert Haas	292794f82b	Remove PID from 'parallel worker' context message. ... Discussion: <bfd204ab-ab1a-792a-b345-0274a09a4b5f@2ndquadrant.com>	10 years ago
Robert Haas	103512cee9	Attempt to fix broken regression test. ... In commit 8c1d9d56e9, I attempted to add a regression test that would fail if the target list was pushed into a parallel worker, but due to brain fade on my part, it just randomly fails whether anything bad or not, because the error check inside the parallel_restricted() function tests whether there is *any process in the system* that is not connected to a client, not whether the process running the query is not connected to a client. A little experimentation has left me pessimistic about the prospects of doing better here in a short amount of time, so let's just fall back to checking that the plan is as we expect and leave the execution-time check for another day.	10 years ago
Robert Haas	8c1d9d56e9	Add regression test for 04ae11f62e. ... The code in this area needs further revision, and it would be best not to re-break the things we've already fixed. Per a gripe from Tom Lane.	10 years ago
Robert Haas	12f862099d	Fix regression test for force_parallel_mode=on. ... Commit 14a254fb52 managed not to exercise the code it was intended to test, and the comment explaining why no "parallel worker" line showed up in the context wasn't right. Amit Kapila, tweaked by me per Amit's analysis.	10 years ago
Noah Misch	14a254fb52	Test parallel query essentials in "make check". ... Clément Prévost and Peter Eisentraut	10 years ago