Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype
От | Tom Lane |
---|---|
Тема | Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype |
Дата | |
Msg-id | 22037.1466129876@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Jun 16, 2016 at 6:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Meh. I think this is probably telling us that trying to repurpose Aggref >> as the representation of a partial aggregate may have been mistaken. > I don't mind if you feel the need to refactor this. I'm not sure yet. What I think we need to work out first is exactly how polymorphic parallel aggregates ought to identify which concrete data types they are using. There were well-defined rules before, but how do we adapt those to two levels of aggregate evaluation? Are we hard-wiring an assumption that the aggregate transtype is the same at both levels? What assumptions do we want to make about the relationship of the data transfer type (the lower level's output type) to the polymorphic input and trans types? A key point here is that the way that polymorphic aggregate support functions used to find out what they were doing is that we'd set up dummy FuncExprs that would satisfy get_call_expr_argtype(). That relied on the fact that the transfn and finalfn calls were specified in a way that corresponded to legal SQL function calls. It's not clear to me whether that statement still holds for parallelized aggregates. regards, tom lane
В списке pgsql-hackers по дате отправления: