Re: [PATCH] Negative Transition Aggregate Functions (WIP)
От | David Rowley |
---|---|
Тема | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
Дата | |
Msg-id | CAApHDvrzfmB_k-Cnw8r-SaPPhFfUGo=839u-cG0-rT90qg0NaA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Negative Transition Aggregate Functions (WIP) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 14, 2014 at 2:29 PM, Tom Lane <span dir="ltr"><<ahref="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span> wrote:<br /><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br/></div> One reason I'm thinking this is that whatever we do to ameliorate<br /> the semantic issues is goingto slow down the forward transition<br /> function --- to no benefit unless the aggregate is being used as a<br /> windowfunction in a moving window. So I'm less than convinced<br /> that we *should* implement any of these designs in thedefault<br /> aggregates, even if we get to the point where we arguably *could*<br /> do it with little risk of functionaldifferences.<br /><br /> regards, tom lane<br /></blockquote></div><br /></div><div class="gmail_extra">Iwas thinking about this earlier today and came up with an idea that perhaps aggregates could support2 transition functions. 1 for normal aggregation and for windows with UNBOUNDED PRECEDING. The 2nd transition functioncould be used when there is a possibility that we would need to perform an inverse transition. This 2nd transitionfunction could do all the extra tracking it needed without having to worry that it would slow down normal aggregation.With numeric that might be tracking each numeric's scale as it enters and exits the window frame. It might evenbe possible to perform inverse transitions with float and double here, we could just internally use numeric, and havethe final function convert back to the original type. Though perhaps that might have the side effect of making floatingpoint calculations too accurate? Or at least not matching the IEEE standards.</div><div class="gmail_extra"><br /></div><divclass="gmail_extra">Of course, I'm not thinking this could be part of this patch, but I thought that I'd postthe idea while all this is fresh in people's heads.</div><div class="gmail_extra"><br /></div><div class="gmail_extra">David</div><divclass="gmail_extra"><br /></div><div class="gmail_extra"><br /></div><div class="gmail_extra"><br/></div></div>
В списке pgsql-hackers по дате отправления: