On Thu, Apr 21, 2016 at 9:16 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2016/04/15 12:02, Robert Haas wrote: >> As previously threatened, I have written some user documentation for >> parallel query. I put it up here: >> >> https://wiki.postgresql.org/wiki/Parallel_Query >> >> This is not totally comprehensive and I can think of a few more >> details that could be added, but it's a pretty good high-level >> overview of what got into 9.6. After this has gotten some feedback >> and polishing, I would like to add a version of this to the SGML >> documentation somewhere. I am not sure where it would fit, but I >> think it's good to document stuff like this. > > Looking at the "Function Labeling For Parallel Safety" section. There is > a sentence: > > "Functions must be marked PARALLEL UNSAFE if they write to the database, > access sequences, change the transaction state even temporarily (e.g. a > PL/pgsql function which establishes an EXCEPTION block to catch errors), > or make persistent changes to settings." > > Then looking at the "postgres_fdw vs. force_parallel_mode on ppc" thread > [1], I wonder if a note on the lines of "or a function that creates *new* > connection(s) to remote server(s)" may be in order. Overkill?
That's not necessarily parallel-unsafe. It's probably parallel-restricted at most. Hey, everybody: I intended to add this to the documentation before 9.6 went out, but that didn't get done. Maybe it'll have to happen later at this point, but can I get some advice on WHERE in the documentation this stuff could be added? Assuming people agree it should be added? The major subsections of the documentation are "Tutorial", "The SQL Language", "Server Administration", "Client Interfaces", "Server Programming", "Reference", "Internals", and "Appendixes", and it's not clear to me that parallel query fits very well into any of those categories. I suppose "Internals" is closest, but that's mostly stuff that typical users won't care about, whereas what I'm trying to document here is what parallel query will look like from a user perspective, not how it looks under the hood. I feel like we need a new major division for operational issues that don't qualify as server administration - e.g. query performance tuning, parallel query, how to decide what indexes to create... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
