From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: assessing parallel-safety |
Date: | 2015-03-16 19:06:32 |
Message-ID: | 5490.1426532792@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Mar 16, 2015 at 2:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Is there a reason not to make a rule that opclass members must be
>>> parallel-safe? I ask because I think it's important that the process
>>> of planning a query be categorically parallel-safe.
>> I'm not seeing the connection between those two statements. The planner
>> doesn't usually execute opclass members, at least not as such.
> Hmm, I guess I'm spouting nonsense there. The way the operator gets
> invoked during planning is that eqsel() calls it. But that doesn't
> require it to be part of an opclass; it just has to be an operator
> that's chosen that eqsel as its selectivity estimator.
Yeah. So what we'd want here is a rule that selectivity estimator
functions must be parallel-safe. For operators using estimators similar
to eqsel() that would imply a requirement on the operator's function
as well, but it's the estimator not any opclass connection that creates
that requirement.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2015-03-16 19:23:17 | Re: Providing catalog view to pg_hba.conf file - Patch submission |
Previous Message | Robert Haas | 2015-03-16 19:02:19 | Re: assessing parallel-safety |