Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype
От | Tom Lane |
---|---|
Тема | Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype |
Дата | |
Msg-id | 18443.1466693846@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype
|
Список | pgsql-hackers |
David Rowley <david.rowley@2ndquadrant.com> writes: > On 23 June 2016 at 11:22, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The behavior that I'd expect (and that I documented) for a deserialization >> function is that it just allocates its result in the current, short-lived >> memory context, since it will be the combine function's responsibility to >> merge that into the long-lived transition state. But it looks to me like >> the deserialization functions in numeric.c are allocating their results >> in the aggregate context, which will mean a leak. (For example, >> numeric_avg_deserialize creates its result using makeNumericAggState >> which forces the result into the agg context.) > Yes, you're right. > In the end I decided to add a makeNumericAggStateCurrentContext() > function which does not perform any memory context switching at all. > It seems like this can be used for the combine functions too, since > they've already switched to the aggregate memory context. This should > save a few cycles during aggregate combine, and not expend any extra > as some alternatives, like adding a flag to makeNumericAggState(). You missed the ones using makePolyNumAggState --- I fixed that and pushed it. regards, tom lane
В списке pgsql-hackers по дате отправления: