Opened 7 years ago
Closed 7 years ago
#3792 closed defect (fixed)
ST_3DIntersects not marked as parallel safe
| Reported by: | robe | Owned by: | robe |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 2.3.4 |
| Component: | postgis | Version: | 2.3.x |
| Keywords: | Cc: |
Description
As paranoidd noted on irc:
13:52:20 paranoidd: hi, folks! 13:53:41 paranoidd: PostGIS newbie here, with a question that's possibly been answered before 13:54:44 paranoidd: so, I've been looking into some query plans and I realized that some of them involving ST_3DIntersects() were serializing the plan through sequential scans 13:55:15 paranoidd: ST_Intersects(), on the other hand, benefits from parallel scans 13:55:44 paranoidd: it looks like ST_Intersects() is marked PARALLEL SAFE, whereas ST_3DIntersects() is not 13:58:38 paranoidd: I see that https://trac.osgeo.org/postgis/ticket/3650 marks certain aggregate functions as parallel safe, so I wonder if (1) the dev team has already gone through a review of ST_3DIntersects() and realized that it's not parallel safe, or (2) a thorough review of this function is still pendi
I don't think there is any reason why we shouldn't mark as parallel safe. This needs to be done for both regular postgis and SFCGAL.
Change History (4)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
It's parallel safe if it doesn't use any temp tables or other tables (at least changes that would causes inconsistent answers between runs) or change system variables. So I think it's fine to mark as parallel safe.
Note:
See TracTickets
for help on using tickets.
I haven't read me up on what criterias have to be met to be paralell safe. In what situations can ST_3DIntersects be used in a parallel plan? Can different rows be delegated to different threads? If so I guess there cannot be any problems with any functions that doesn't do aggregation or unnesting?
Sorry for not being more updated on parallel challenges…