Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Parallel Seq Scan
Date
Msg-id 20151016002349.GA227414@tornado.leadboat.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Oct 15, 2015 at 12:05:53PM -0400, Robert Haas wrote:
> On Thu, Oct 15, 2015 at 1:51 AM, Noah Misch <noah@leadboat.com> wrote:

> >> This wouldn't require any
> >> modification to the current plpgsql_param_fetch() at all, but the new
> >> function would steal its bms_is_member() test.  Furthermore, no user
> >> of ParamListInfo other than plpgsql needs to care at all -- which,
> >> with your proposals, they would.
> >
> > To my knowledge, none of these approaches would compel existing users to care.
> > They would leave paramMask or paramListCopyHook NULL and get today's behavior.
> 
> Well, looking at this proposal:
> 
> Bitmapset  *paramMask;  /* if non-NULL, ignore params lacking a 1-bit */
> 
> I read that to imply that every consumer of ParamListInfo objects
> would need to account for the possibility of getting one with a
> non-NULL paramMask.

Agreed.  More specifically, I had in mind for copyParamList() to check the
mask while e.g. ExecEvalParamExtern() would either check nothing or merely
assert that any mask included the requested parameter.  It would be tricky to
verify that as safe, so ...

> Would it work to define this as "if non-NULL,
> params lacking a 1-bit may be safely ignored"?  Or some other tweak
> that basically says that you don't need to care about this, but you
> can if you want to.

... this is a better specification.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?
Next
From: Jim Nasby
Date:
Subject: Re: Improve the concurency of vacuum full table and select statement on the same relation