Re: Parallel Seq Scan
От | Noah Misch |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | 20151024163132.GA436059@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Parallel Seq Scan
|
Список | pgsql-hackers |
On Sat, Oct 24, 2015 at 07:49:07AM -0400, Robert Haas wrote: > On Fri, Oct 23, 2015 at 9:38 PM, Noah Misch <noah@leadboat.com> wrote: > > Since that specification permits ParamListInfo consumers to ignore paramMask, > > the plpgsql_param_fetch() change from copy-paramlistinfo-fixes.patch is still > > formally required. > > So why am I not just doing that, then? Seems a lot more surgical. do $$ declareparam_unused text := repeat('a', 100 * 1024 * 1024);param_used oid := 403; beginperform count(*) from pg_am where oid = param_used; end $$; I expect that if you were to inspect the EstimateParamListSpace() return values when executing that, you would find that it serializes the irrelevant 100 MiB datum. No possible logic in plpgsql_param_fetch() could stop that from happening, because copyParamList() and SerializeParamList() call the paramFetch hook only for dynamic parameters. Cursors faced the same problem, which is the raison d'être for setup_unshared_param_list().
В списке pgsql-hackers по дате отправления: