Amit Kapila <amit.kapil...@gmail.com> writes:
> To add to whatever has been said above, intention of adding that flag
> was also to avoid adding new nodes for parallelism. Basically modify
> the existing nodes (like SeqScan) to take care of whatever is needed
> for parallel execution.
TBH, I would say that that's a damn-fool idea. I think you should instead
create a separate ParallelSeqScan path type and plan type, and the same
for every other thing that becomes parallel-aware. The planner does not
normally[1] use the same path type to represent two fundamentally different
execution plans with enormously different cost estimates, but that is the
direction you want to push in for parallel query. I think it will lead to
a mess: lots of unreadable code that has to do things in a way unlike the
code around it, and lots of bugs-of-omission in places that should have
distinguished seq and parallel cases but didn't.
regards, tom lane
[1] Yes, I'm aware that UniquePath is an exception. It has reasons to
live though, in particular that if it were multiple path types there would
still need to be places that understood the common property of those path
types all delivering unique results. I do not see any corresponding
benefit of fuzzing the distinction between SeqScan and ParallelSeqScan.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
