Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
Date: 2016-06-09 17:44:44
Message-ID: 7106.1465494284@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It seems like the only reason that we would need such a flag is that
>> applying has_parallel_hazard() to a Var is a bit expensive thanks to
>> the typeid_is_temp() test --- but if you ask me, that test is stupid
>> and should be removed. What's the argument for supposing that a temp
>> table's rowtype is any more mutable intra-query than any other rowtype?

> That error is coming from relation_open(). It might be possible to
> find a way to nerf the check in relation_open() enough to let this
> case work while making the cases that we need to fail still fail,

Well, yeah, you could remove it. It's inappropriate. The right place
for such an error check is an attempt to actually access any data within
a temp table, ie someplace in localbuf.c. There is no reason a worker
shouldn't be allowed to look at the catalog entries for a temp table;
they're just like any other catalog entries.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-06-09 17:57:15 Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
Previous Message Robert Haas 2016-06-09 17:26:41 Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-09 17:47:34 Re: parallel workers and client encoding
Previous Message Robert Haas 2016-06-09 17:34:14 Re: parallel workers and client encoding