Re: Parallel Seq Scan

On Thu, Oct 15, 2015 at 1:51 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> Tests of prm->prmtype and paramLI->paramFetch appear superfluous. Given that
> the paramListCopyHook callback would return a complete substitute
> ParamListInfo, I wouldn't expect SerializeParamList() to examine the the
> original paramLI->params at all. If that's correct, the paramListCopyHook
> design sounds fine. However, its implementation will be more complex than
> paramMask would have been.

Well, I think there are two use cases we care about. If the
ParamListInfo came from Bind parameters sent via a protocol message,
then it will neither have a copy method nor require one. If it came
from some source that plays fancy games, like PL/pgsql, then it needs
a safe way to copy the list.

>> 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. 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company