Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted |
Дата | |
Msg-id | CA+TgmoaMEcATR7cDFmXHrQ0kipKDqZXwKj_QT8QnFqtntoPO_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Jun 9, 2016 at 8:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> There's one other related thing I'm concerned about, which is that the >>> code in namespace.c that manages pg_temp doesn't know anything about >>> parallelism. So it will interpret pg_temp to mean the pg_temp_NNN >>> schema for its own backend ID rather than the leader's backend ID. >>> I'm not sure that's a problem, but I haven't thought deeply about it. > >> Hmmm. I'll take a look. > > Yeah, that was pretty broken, but I believe I've fixed it. Thanks. Looks reasonable on a quick once-over. For the record, I think much of what constitutes "broken" is arbitrary here - anything that doesn't work can be labelled "well, that's not supported under parallel query, label your function parallel-restricted or parallel-unsafe". And I think we're going to have to take exactly that approach in many cases. I have no illusions that the current infrastructure covers everything that users will want to do, and I think we'll be uncovering and removing limitations of this sort for a long time. But clearly the more state we synchronize, the happier users will be. I probably should have done something like what you did here sooner, but I didn't think it could be done that simply. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: