From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres 11 release notes |
Date: | 2018-05-17 00:24:43 |
Message-ID: | 20180517002443.GC23890@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-www |
On Wed, May 16, 2018 at 09:55:05AM +0530, Amit Kapila wrote:
> On Wed, May 16, 2018 at 12:17 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Tue, May 15, 2018 at 08:45:07AM +0530, Amit Kapila wrote:
> >> No, it is not like that. We divide the scan among workers and each
> >> worker should perform projection of the rows it scanned (after
> >> applying filter). Now, if the expensive functions are part of target
> >> lists, then we can push the computation of expensive functions (as
> >> part of target list) in workers which will divide the work.
> >>
> >> > Really? Do
> >> > we run each column in its own worker or do we split the result set into
> >> > parts and run those in parallel? How do we know, just the function call
> >> > costs?
> >> >
> >>
> >> The function's cost can be determined via pg_proc->procost. For this
> >> particular case, you can refer the call graph -
> >> create_pathtarget->set_pathtarget_cost_width->cost_qual_eval_node->cost_qual_eval_walker->get_func_cost
> >>
> >> > I can admit I never saw that coming.
> >> >
> >>
> >> I think the use case becomes interesting with parallel query because
> >> now you can divide such cost among workers.
> >>
> >> Feel free to ask more questions if above doesn't clarify the usage of
> >> these features.
> >
> > OK, I have added the following release note item for both of these:
> >
> > 2017-11-16 [e89a71fb4] Pass InitPlan values to workers via Gather (Merge).
> > 2018-03-29 [3f90ec859] Postpone generate_gather_paths for topmost scan/join rel
> > 2018-03-29 [11cf92f6e] Rewrite the code that applies scan/join targets to paths
> >
> > Allow single-evaluation queries, e.g. <literal>FROM</literal>
> > clause queries, and functions in the target list to be
> > parallelized (Amit Kapila, Robert Haas)
> >
>
> Sorry, but it is not clear to me what you intend to say by "e.g.
> <literal>FROM</literal> clause queries"? What I could imagine is
> something like "e.g. queries in <literal>WHERE</literal> clause that
> return aggregate value"
Oh, sorry, changed to:
Allow single-evaluation queries, e.g. <literal>WHERE</literal>
clause aggregate queries, and functions in the target list to be
parallelized (Amit Kapila, Robert Haas)
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-05-17 00:26:44 | Re: Postgres 11 release notes |
Previous Message | Bruce Momjian | 2018-05-17 00:20:49 | Re: Postgres 11 release notes |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-05-17 00:26:44 | Re: Postgres 11 release notes |
Previous Message | Bruce Momjian | 2018-05-17 00:20:49 | Re: Postgres 11 release notes |