2010/10/1 Hitoshi Harada <umi.tan...@gmail.com>: > 2010/10/2 Tom Lane <t...@sss.pgh.pa.us>: >> Hitoshi Harada <umi.tan...@gmail.com> writes: >>> 2010/10/2 Tom Lane <t...@sss.pgh.pa.us>: >>>> The implementation I would've expected to see is to do the sort and then >>>> have two code paths for retrieving the median, depending on whether the >>>> sort result is all in memory or not. >> >>> Hm? The problem we encountered in the middle of the patch is there is >>> no chance to call tuplesort_end if median is called in moving frame >>> window aggregate because final function is called multiple times >>> during moving. >> >> Well, if you haven't got a solution for that, then this patch isn't >> ready for prime time. >> >> It's entirely possible that median as a window function is intractable. >> I'd rather have it throwing error than offer an implementation that will >> fall over as soon as the window gets large. > > Well, that sounds like the conclusion. It is a shame, but we have to > throw an error from median() in the window aggregate, if Pavel does > not have any better solution. And as an aggregate function only, the > patch is ready if the window-related parts are removed. >
I am sorry - I don't have a better solution. Classic algorithm isn't well for window aggregate - it needs a sort after any append a new item. Maybe we can use a separate functionality based on estimated values for a windows. I read some articles about it. But this is work on longer time - all articles about this topic are experimental. More I am not mathematician - so I am not able to review these methods. Today or tomorrow I'll send a updated patch without support a window aggregates. Regards Pavel Stehule > Regards, > > > -- > Hitoshi Harada > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
