On Sat, Nov 1, 2014 at 1:09 AM, Simon Riggs <simon@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
