Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Parallel Seq Scan
Дата
Msg-id 20151016002349.GA227414@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Improve the concurency of vacuum full table and select statement on the same relation