On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > On Mon, Jun 13, 2016 at 11:02 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> BTW, decent regression tests could be written without the need to create > >> enormous tables if the minimum rel size in create_plain_partial_paths() > >> could be configured to something less than 1000 blocks. I think it's > >> fairly crazy that that arbitrary constant is hard-wired anyway. Should > >> we make it a GUC? > > > That was proposed before, and I didn't do it mostly because I couldn't > > think of a name for it that didn't sound unbelievably corny. > > min_parallel_relation_size, or min_parallelizable_relation_size, or > something like that? >
You are right that such a variable will make it simpler to write tests for parallel query. I have implemented such a guc and choose to keep the name as min_parallel_relation_size. One thing to note is that in function create_plain_partial_paths(), curently it is using PG_INT32_MAX/3 for parallel_threshold to check for overflow, I have changed it to INT_MAX/3 so as to be consistent with guc.c. I am not sure if it is advisable to use PG_INT32_MAX in guc.c as other similar parameters use INT_MAX. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
min_parallel_relation_size_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
