On Sat, Nov 1, 2014 at 1:09 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > What are the specific restrictions you are suggesting we place on > parallel workers? We need that definition clear so we can decide how > to mark the functions. If we don't know, which is easily > understandable, then the best way to find that out is to build a > restricted solution and to expand slowly outwards to find problems. > > An obvious milestone there is whether a function contains SQL, which > is the point chosen by some other databases. I personally hope to > expand upon that, but it would be useful to reach it first and then > continue from there. > > I was already thinking of implementing CONTAINS NO SQL as a SQL > Standard function marking since it can be used to optimize COPY > further.
I've written some fairly extensive thoughts on this topic at http://wiki.postgresql.org/wiki/Parallel_Sort Personally, I tend to focus more on what needs to be allowed in parallel workers than what needs to be prohibited. The motivation for this patch is simple: 1. Any non-trivial piece of PostgreSQL code is likely to contain syscache lookups. 2. Syscache lookups had better work in parallel workers, or they'll be all but useless. 3. Some of those syscache lookups will be satisfied from cache, but sometimes we'll need to actually read the system catalogs. 4. That requires locks. 5. Gosh, we'd better not deadlock. There's a lot of infrastructure that I think will work fine in parallel mode without any changes. Buffer locking, buffer pins, buffer lookups, and lwlocks, for example, I expect to all just work without any real. But heavyweight locks and invalidation messages seem like they'll need a bit of surgery to work correctly in this environment. -- 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
