On Fri, Nov 10, 2017 at 12:05 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Nov 9, 2017 at 12:08 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> This change looks suspicious to me. I think here we can't use the >> tupDesc constructed from targetlist. One problem, I could see is that >> the check for hasOid setting in tlist_matches_tupdesc won't give the >> correct answer. In case of the scan, we use the tuple descriptor >> stored in relation descriptor which will allow us to take the right >> decision in tlist_matches_tupdesc. If you try the statement CREATE >> TABLE as_select1 AS SELECT * FROM pg_class WHERE relkind = 'r'; in >> force_parallel_mode=regress, then you can reproduce the problem I am >> trying to highlight. > > I tried this, but nothing seemed to be obviously broken. Then I > realized that the CREATE TABLE command wasn't using parallelism, so I > retried with parallel_setup_cost = 0, parallel_tuple_cost = 0, and > min_parallel_table_scan_size = 0. That got it to use parallel query, > but I still don't see anything broken. Can you clarify further? >
Have you set force_parallel_mode=regress; before running the statement? If so, then why you need to tune other parallel query related parameters? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
