On Mon, Oct 12, 2015 at 5:15 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > Right, it should initialize parallel scan properly even for non-synchronized > scans. Fixed the issue in attached patch. Rebased heap rescan is > attached as well. >
Attached is rebased patch for partial seqscan support. The major change in this patch is to prohibit generation of parallel path for a relation if quals contain restricted functions and or initplan/subplan. Also as Gather node in itself is not a projection capable node, so if target list contains any expression, it adds a Result node on top of it. I think this will take care of the cases where if target list contains any parallel-unsafe expressions (like restricted functions and or initplans/subplans), then those won't be pushed to backend workers. Another options I have considered for target list are: 1. Assess the tlist passed to query_planner to see if it contains any parallel- unsafe expression, if so then don't generate any parallel path for that subquery. Though this idea will deal with prohibition at sub-query level, still I think it is not the best way as subquery could contain join and for some of the relations participating in join, we could have parallel-paths, but doing this way will restrict parallel paths for all the relations participating in sub-query. 2. To handle join case in sub-uery, we can pass tlist passed to query_planner() till create_parallelscan_paths() and then check if any target entry contains unsafe expression and if that expression has Var that belongs to current relation, then don't allow parallel path else allow it. Doing this way we might not be able to catch the cases as below, where expression in target doesn't belong to any relation. select c1, pg_restricted() from t1; We can think of other ways to handle target list containing parallel-unsafe expression, if whatever done in patch is not sufficient. We might want to support initplans/subplans and restricted function evaluation once the required infrastructure to support the same is in-place. I think those could be done as separate patches. Notes - 1. This eventually needs to be rebased on top of bug-fixes posted by Robert for parallelism [1]. One of the temporary fix has been done in ExecReScanGather() to allow rescan of Gather node, the actual fix will be incorporated by bug-fix patches. 2. Done pgindent on changed files, so you might see some indentation changes which are not directly related to this patch, but are from previous parallel seq scan work especially in execParallel.c. 3. Apply this patch on top of parallel heap scan patches [2] [1] - http://www.postgresql.org/message-id/ca+tgmoapgkdy_z0w9mhqzcgso2t_t-4_v36dxakim+x_fyp...@mail.gmail.com [2] - http://www.postgresql.org/message-id/caa4ek1kcymw+-vjuagsxf-s4k-0x3dbxdcw5hem+qsgergx...@mail.gmail.com With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
parallel_seqscan_partialseqscan_v20.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