| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Jeff Davis <pgsql(at)j-davis(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel Seq Scan |
| Date: | 2015-10-16 00:23:49 |
| Message-ID: | 20151016002349.GA227414@tornado.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)leadboat(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2015-10-16 00:28:09 | Re: Improve the concurency of vacuum full table and select statement on the same relation |
| Previous Message | Thomas Munro | 2015-10-16 00:07:48 | Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c? |