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 по дате отправления: