On Wed, Oct 13, 2010 at 10:37 PM, Greg Stark wrote:
> On Wed, Oct 13, 2010 at 5:54 PM, Robert Haas wrote:
>> Or to put it more bluntly - what is the "problem with planner and hash
>> agg" that all of these functions need to solve? And why does it need
>> a flag in pg_proc? Why can't't we leave
2010/10/14 Robert Haas :
> On Wed, Oct 13, 2010 at 6:56 AM, Pavel Stehule
> wrote:
>> 2010/10/13 Pavel Stehule :
>>> 2010/10/13 Peter Eisentraut :
On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
> The problem is in interface. The original patch did it, but I removed
> it. We
On Wed, Oct 13, 2010 at 6:56 AM, Pavel Stehule wrote:
> 2010/10/13 Pavel Stehule :
>> 2010/10/13 Peter Eisentraut :
>>> On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
The problem is in interface. The original patch did it, but I removed
it. We cannot to unsure immutability of so
On Wed, Oct 13, 2010 at 5:54 PM, Robert Haas wrote:
> Or to put it more bluntly - what is the "problem with planner and hash
> agg" that all of these functions need to solve? And why does it need
> a flag in pg_proc? Why can't't we leave it to the individual
> functions to perform a sort of one
2010/10/13 Pavel Stehule :
> 2010/10/13 Peter Eisentraut :
>> On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
>>> The problem is in interface. The original patch did it, but I removed
>>> it. We cannot to unsure immutability of some parameters now.
>>
>> How about you store the "immutable"
2010/10/13 Peter Eisentraut :
> On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
>> The problem is in interface. The original patch did it, but I removed
>> it. We cannot to unsure immutability of some parameters now.
>
> How about you store the "immutable" parameter in the transition state
On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
> The problem is in interface. The original patch did it, but I removed
> it. We cannot to unsure immutability of some parameters now.
How about you store the "immutable" parameter in the transition state
and error out if it changes between c
Hello
I am looking on SQL standard for some info about "within group"
clause. This clause is necessary for functions:
rank, dense_rank, cume_dist, percent_rank and percentile_disc and
persentile_cont. These functions needs a clause "WITHIN GROUP".
If I understand, then these functions are not si
2010/10/12 Hitoshi Harada :
> 2010/10/12 Pavel Stehule :
>> Hello
>>
>> 2010/10/11 Greg Stark :
>>> On Sun, Oct 10, 2010 at 2:16 PM, Tom Lane wrote:
It was pointed out upthread that while median isn't presently
in the standard, Oracle defines it in terms of percentile_cont(0.5)
whic
2010/10/12 Pavel Stehule :
> Hello
>
> 2010/10/11 Greg Stark :
>> On Sun, Oct 10, 2010 at 2:16 PM, Tom Lane wrote:
>>> It was pointed out upthread that while median isn't presently
>>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>>> which *is* in the standard.
>>
>> Uhmm, t
Hello
2010/10/11 Greg Stark :
> On Sun, Oct 10, 2010 at 2:16 PM, Tom Lane wrote:
>> It was pointed out upthread that while median isn't presently
>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>> which *is* in the standard.
>
> Uhmm, then why don't we implement that? We co
> Uhmm, then why don't we implement that? We could provide median() as a
> short-cut but percentile_cont() doesn't sound much harder to implement
> than median() and more general.
I could really use percentile_cont(0.9), actually, for query
response-time analysis.
--
On Sun, Oct 10, 2010 at 2:16 PM, Tom Lane wrote:
> It was pointed out upthread that while median isn't presently
> in the standard, Oracle defines it in terms of percentile_cont(0.5)
> which *is* in the standard.
Uhmm, then why don't we implement that? We could provide median() as a
short-cut but
On 11 October 2010 19:05, Tom Lane wrote:
> Dean Rasheed writes:
>> On 11 October 2010 18:48, Tom Lane wrote:
>>> And? If the memory requirement actually fits, you're in good shape.
>
>> Yeah but the actual memory requirement, if it uses a hash aggregate,
>> is over 1GB, and could easily be muc
Dean Rasheed writes:
> On 11 October 2010 18:48, Tom Lane wrote:
>> And? If the memory requirement actually fits, you're in good shape.
> Yeah but the actual memory requirement, if it uses a hash aggregate,
> is over 1GB, and could easily be much higher.
In that case the estimate of 30K per in
On 11 October 2010 18:48, Tom Lane wrote:
> Dean Rasheed writes:
>> On 11 October 2010 18:37, Tom Lane wrote:
>>> Sure it would: an estimate of 30K would keep the planner from using
>>> hash aggregation.
>
>> Not if work_mem was 10MB.
>
> And? If the memory requirement actually fits, you're in
Dean Rasheed writes:
> On 11 October 2010 18:37, Tom Lane wrote:
>> Sure it would: an estimate of 30K would keep the planner from using
>> hash aggregation.
> Not if work_mem was 10MB.
And? If the memory requirement actually fits, you're in good shape.
regards, tom lan
On 11 October 2010 18:37, Tom Lane wrote:
> Dean Rasheed writes:
>> The estimate of 200 x 8K is below work_mem, so it uses a hash
>> aggregate. In reality, each tuplesort allocates around 30K initially,
>> so it very quickly uses over 1GB. A better estimate for the aggregate
>> wouldn't improve t
Dean Rasheed writes:
> The estimate of 200 x 8K is below work_mem, so it uses a hash
> aggregate. In reality, each tuplesort allocates around 30K initially,
> so it very quickly uses over 1GB. A better estimate for the aggregate
> wouldn't improve this situation much.
Sure it would: an estimate o
On 11 October 2010 16:44, Tom Lane wrote:
> Dean Rasheed writes:
>> On 11 October 2010 15:03, Tom Lane wrote:
>>> Reflecting on it, I think it'd be best to allow an agg to
>>> provide an estimation function that'd be told the input data type and
>>> expected number of rows --- even on a per-aggr
Dean Rasheed writes:
> On 11 October 2010 15:03, Tom Lane wrote:
>> Reflecting on it, I think it'd be best to allow an agg to
>> provide an estimation function that'd be told the input data type and
>> expected number of rows --- even on a per-aggregate basis, a constant
>> estimate just isn't go
On 11 October 2010 15:03, Tom Lane wrote:
> Dean Rasheed writes:
>> On 10 October 2010 22:16, Tom Lane wrote:
>>> BTW, as far as the implementation issues go, telling tuplesort that it
>>> can use gigabytes of memory no matter what seems quite unacceptable.
>>> Put this thing into a hash aggrega
On Mon, Oct 11, 2010 at 10:08 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Oct 10, 2010 at 5:16 PM, Tom Lane wrote:
>>> It was pointed out upthread that while median isn't presently
>>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>>> which *is* in the standard. W
Robert Haas writes:
> On Sun, Oct 10, 2010 at 5:16 PM, Tom Lane wrote:
>> It was pointed out upthread that while median isn't presently
>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>> which *is* in the standard. What I read in SQL:2008 is that
>> percentile_cont is defi
Dean Rasheed writes:
> On 10 October 2010 22:16, Tom Lane wrote:
>> BTW, as far as the implementation issues go, telling tuplesort that it
>> can use gigabytes of memory no matter what seems quite unacceptable.
>> Put this thing into a hash aggregation and you'll blow out your memory
>> in no tim
On Sun, Oct 10, 2010 at 5:16 PM, Tom Lane wrote:
> It was pointed out upthread that while median isn't presently
> in the standard, Oracle defines it in terms of percentile_cont(0.5)
> which *is* in the standard. What I read in SQL:2008 is that
> percentile_cont is defined for all numeric types (
On 11 October 2010 10:55, Pavel Stehule wrote:
>> BTW, why has percentile been removed from this patch? As the more
>> general, and SQL standard function, that would seem to be the more
>> useful one to include. Upthread it was mentioned that there is already
>> an ntile window function, but actua
2010/10/11 Dean Rasheed :
> On 10 October 2010 22:16, Tom Lane wrote:
>> It was pointed out upthread that while median isn't presently
>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>> which *is* in the standard. What I read in SQL:2008 is that
>> percentile_cont is define
On 10 October 2010 22:16, Tom Lane wrote:
> It was pointed out upthread that while median isn't presently
> in the standard, Oracle defines it in terms of percentile_cont(0.5)
> which *is* in the standard. What I read in SQL:2008 is that
> percentile_cont is defined for all numeric types (returni
2010/10/10 Tom Lane :
> Dean Rasheed writes:
>> In the meantime, the attached variation of the patch fixes the temp
>> file issue and will support all 3 cases. It gives OK performance for
>> (1) and (2), and poor performance for (3). That could be viewed as a
>> future development task, which perh
Dean Rasheed writes:
> In the meantime, the attached variation of the patch fixes the temp
> file issue and will support all 3 cases. It gives OK performance for
> (1) and (2), and poor performance for (3). That could be viewed as a
> future development task, which perhaps the window function API
On 5 October 2010 13:14, Hitoshi Harada wrote:
> 2010/10/5 Dean Rasheed :
>> On 5 October 2010 07:04, Hitoshi Harada wrote:
>> Extrapolating from few quick timing tests, even in the best case, on
>> my machine, it would take 7 days for the running median to use up
>> 100MB, and 8 years for it to
2010/10/5 Dean Rasheed :
> On 5 October 2010 07:04, Hitoshi Harada wrote:
> Extrapolating from few quick timing tests, even in the best case, on
> my machine, it would take 7 days for the running median to use up
> 100MB, and 8 years for it to use 2GB. So setting the tuplesort's
> workMem to 2GB (
On 5 October 2010 07:04, Hitoshi Harada wrote:
> 2010/10/5 Dean Rasheed :
>> On 4 October 2010 18:22, Robert Haas wrote:
>>> On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed
>>> wrote:
That requires a new sort for each row. I generated this with a minor
tweak to Pavel's patch to just rest
2010/10/5 Dean Rasheed :
> On 4 October 2010 18:22, Robert Haas wrote:
>> On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed
>> wrote:
>>> That requires a new sort for each row. I generated this with a minor
>>> tweak to Pavel's patch to just restart the tuplesort each time (the
>>> "quick-fix" soluti
On 4 October 2010 18:22, Robert Haas wrote:
> On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed wrote:
>> That requires a new sort for each row. I generated this with a minor
>> tweak to Pavel's patch to just restart the tuplesort each time (the
>> "quick-fix" solution). The problem is that performanc
On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed wrote:
> That requires a new sort for each row. I generated this with a minor
> tweak to Pavel's patch to just restart the tuplesort each time (the
> "quick-fix" solution). The problem is that performance really sucks,
> because it is an O(n^2 log(n)) a
On Sun, Oct 3, 2010 at 11:58 PM, Dean Rasheed wrote:
> The problem is that performance really sucks,
> because it is an O(n^2 log(n)) algorithm. I don't see an easy way
> around that without significant new infrastructure, as Greg describes,
> or a completely different algorithm.
Resorting for ea
On 4 October 2010 07:36, Hitoshi Harada wrote:
> 2010/10/4 Greg Stark :
>> On Sun, Oct 3, 2010 at 7:06 AM, Hitoshi Harada wrote:
>>> And I'm now thinking about how to make median happen in window
>>> aggregate.
>>
>> If you were to do this by extending tuplesort what extra features
>> would tuple
2010/10/4 Greg Stark :
> On Sun, Oct 3, 2010 at 7:06 AM, Hitoshi Harada wrote:
>> And I'm now thinking about how to make median happen in window
>> aggregate.
>
> If you were to do this by extending tuplesort what extra features
> would tuplesort need?
I don't think we need to extend tuplesort wh
Hello
2010/10/3 Hitoshi Harada :
> 2010/10/2 Pavel Stehule :
>> Hello
>>
>> updated version
>> * memsort removed
>> * window aggregate support blocked
>
> I ran this patch and it looks good for committer.
> Just one thing, in src/backend/utils/adt/Makefile median.o to compile
> the new file is m
On Sun, Oct 3, 2010 at 7:06 AM, Hitoshi Harada wrote:
> And I'm now thinking about how to make median happen in window
> aggregate.
If you were to do this by extending tuplesort what extra features
would tuplesort need?
Would tuplesort need the ability to insert additional records into an
alread
2010/10/2 Pavel Stehule :
> Hello
>
> updated version
> * memsort removed
> * window aggregate support blocked
I ran this patch and it looks good for committer.
Just one thing, in src/backend/utils/adt/Makefile median.o to compile
the new file is missing.
And I'm now thinking about how to make
Hello
updated version
* memsort removed
* window aggregate support blocked
Regards
Pavel
2010/10/1 Pavel Stehule :
> 2010/10/1 Hitoshi Harada :
>> 2010/10/2 Tom Lane :
>>> Hitoshi Harada writes:
2010/10/2 Tom Lane :
> The implementation I would've expected to see is to do the sort
2010/10/1 Hitoshi Harada :
> 2010/10/2 Tom Lane :
>> Hitoshi Harada writes:
>>> 2010/10/2 Tom Lane :
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.
2010/10/2 Kevin Grittner :
> Tom Lane wrote:
>> Hitoshi Harada writes:
>>> Another suggestion?
>>
>> 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.
>
> Woul
2010/10/2 Tom Lane :
> Hitoshi Harada writes:
>> 2010/10/2 Tom Lane :
>>> 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 encountere
Hitoshi Harada writes:
> 2010/10/2 Tom Lane :
>> 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
2010/10/2 Tom Lane :
> Hitoshi Harada writes:
>> Another suggestion?
>
> 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 th
Tom Lane wrote:
> Hitoshi Harada writes:
>> Another suggestion?
>
> 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.
Would it make sense to accumulate value/
Hitoshi Harada writes:
> Another suggestion?
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.
regards, tom lane
--
Sent via pgsql-hackers
2010/10/1 Tom Lane :
> Hitoshi Harada writes:
>> 2010/10/1 Tom Lane :
>>> If this patch tries to force the entire sort to happen in memory,
>>> it is not committable.
>
>> What about array_agg()? Doesn't it exceed memory even if the huge data come
>> in?
>
> Yeah, but for array_agg the user shoul
On Fri, Oct 1, 2010 at 10:11 AM, Hitoshi Harada wrote:
> 2010/10/1 Tom Lane :
>> Hitoshi Harada writes:
>>> 2010/9/26 Pavel Stehule :
This patch needs a few work - can share a compare functionality with
tuplesort.c, but I would to verify a concept now.
>>
>>> Sorry for delay. I read the
Hitoshi Harada writes:
> 2010/10/1 Tom Lane :
>> If this patch tries to force the entire sort to happen in memory,
>> it is not committable.
> What about array_agg()? Doesn't it exceed memory even if the huge data come
> in?
Yeah, but for array_agg the user should be expecting a result of
appro
2010/10/1 Tom Lane :
> Hitoshi Harada writes:
>> 2010/9/26 Pavel Stehule :
>>> This patch needs a few work - can share a compare functionality with
>>> tuplesort.c, but I would to verify a concept now.
>
>> Sorry for delay. I read the patch and it seems the result is sane. For
>> window function c
2010/10/1 Tom Lane :
> Hitoshi Harada writes:
>> 2010/9/26 Pavel Stehule :
>>> This patch needs a few work - can share a compare functionality with
>>> tuplesort.c, but I would to verify a concept now.
>
>> Sorry for delay. I read the patch and it seems the result is sane. For
>> window function c
Hitoshi Harada writes:
> 2010/9/26 Pavel Stehule :
>> This patch needs a few work - can share a compare functionality with
>> tuplesort.c, but I would to verify a concept now.
> Sorry for delay. I read the patch and it seems the result is sane. For
> window function calls, I agree that the curren
Hello
2010/10/1 Hitoshi Harada :
> 2010/9/26 Pavel Stehule :
>> Hello,
>>
>> there is updated version - with support of window clause. The limits
>> are work_mem for using inside window aggregate or unlimited when it is
>> used as standard query.
>>
>> This patch needs a few work - can share a com
2010/9/26 Pavel Stehule :
> Hello,
>
> there is updated version - with support of window clause. The limits
> are work_mem for using inside window aggregate or unlimited when it is
> used as standard query.
>
> This patch needs a few work - can share a compare functionality with
> tuplesort.c, but
Hello,
there is updated version - with support of window clause. The limits
are work_mem for using inside window aggregate or unlimited when it is
used as standard query.
This patch needs a few work - can share a compare functionality with
tuplesort.c, but I would to verify a concept now.
Commen
2010/9/23 David Fetter :
> On Thu, Sep 23, 2010 at 08:27:38PM +0200, Pavel Stehule wrote:
>> 2010/9/23 Hitoshi Harada :
>> > 2010/9/23 Pavel Stehule :
>> >> Hello
>> >>
>> >> 2010/9/22 Hitoshi Harada :
>> >>> 2010/9/22 Pavel Stehule :
>> Hello
>>
>> I found probably hard problem in c
On Thu, Sep 23, 2010 at 08:27:38PM +0200, Pavel Stehule wrote:
> 2010/9/23 Hitoshi Harada :
> > 2010/9/23 Pavel Stehule :
> >> Hello
> >>
> >> 2010/9/22 Hitoshi Harada :
> >>> 2010/9/22 Pavel Stehule :
> Hello
>
> I found probably hard problem in cooperation with window functions :(
2010/9/23 Hitoshi Harada :
> 2010/9/23 Pavel Stehule :
>> Hello
>>
>> 2010/9/22 Hitoshi Harada :
>>> 2010/9/22 Pavel Stehule :
Hello
I found probably hard problem in cooperation with window functions :(
>>
>> maybe I was confused. I found a other possible problems.
>>
>> The problem
2010/9/23 Pavel Stehule :
> Hello
>
> 2010/9/22 Hitoshi Harada :
>> 2010/9/22 Pavel Stehule :
>>> Hello
>>>
>>> I found probably hard problem in cooperation with window functions :(
>
> maybe I was confused. I found a other possible problems.
>
> The problem with median function is probably inside
sorry
little bit fixed patch
Pavel
2010/9/23 Pavel Stehule :
> Hello
>
> I moved a "median" function to core.
>
> + doc part
> + regress test
>
> Regards
>
> Pavel Stehule
>
>
> 2010/9/20 Hitoshi Harada :
>> 2010/8/19 Pavel Stehule :
>>> Hello
>>>
>>> I am sending a prototype implementation of f
Hello
I moved a "median" function to core.
+ doc part
+ regress test
Regards
Pavel Stehule
2010/9/20 Hitoshi Harada :
> 2010/8/19 Pavel Stehule :
>> Hello
>>
>> I am sending a prototype implementation of functions median and
>> percentile. This implementation is very simple and I moved it to
Hello
2010/9/22 Hitoshi Harada :
> 2010/9/22 Pavel Stehule :
>> Hello
>>
>> I found probably hard problem in cooperation with window functions :(
>>
>> tuplesort_begin_datum creates child context inside aggcontext. This
>> context is used for tuplestore. But when this function is called from
>> Wi
2010/9/22 Hitoshi Harada :
> 2010/9/22 Pavel Stehule :
>> Hello
>>
>> I found probably hard problem in cooperation with window functions :(
>>
>> tuplesort_begin_datum creates child context inside aggcontext. This
>> context is used for tuplestore. But when this function is called from
>> WindowAgg
2010/9/22 Hitoshi Harada :
> 2010/9/22 Pavel Stehule :
>> 2010/9/21 Robert Haas :
>>> On Tue, Sep 21, 2010 at 4:28 PM, Pavel Stehule
>>> wrote:
> * Cosmetic coding style should be more appropriate, including trailing
> white spaces and indentation positions.
can you specify wher
2010/9/22 Pavel Stehule :
> Hello
>
> I found probably hard problem in cooperation with window functions :(
>
> tuplesort_begin_datum creates child context inside aggcontext. This
> context is used for tuplestore. But when this function is called from
> WindowAgg_Aggregates context - someone drops
2010/9/22 Pavel Stehule :
> 2010/9/21 Robert Haas :
>> On Tue, Sep 21, 2010 at 4:28 PM, Pavel Stehule
>> wrote:
* Cosmetic coding style should be more appropriate, including trailing
white spaces and indentation positions.
>>>
>>> can you specify where, please?
>>
>> I noticed a lot of
2010/9/21 Robert Haas :
> On Tue, Sep 21, 2010 at 4:28 PM, Pavel Stehule
> wrote:
>>> * Cosmetic coding style should be more appropriate, including trailing
>>> white spaces and indentation positions.
>>
>> can you specify where, please?
>
> I noticed a lot of problems in this area when working o
On Tue, Sep 21, 2010 at 4:28 PM, Pavel Stehule wrote:
>> * Cosmetic coding style should be more appropriate, including trailing
>> white spaces and indentation positions.
>
> can you specify where, please?
I noticed a lot of problems in this area when working on your \ef /
\sf patch, too. Traili
Hello
I found probably hard problem in cooperation with window functions :(
tuplesort_begin_datum creates child context inside aggcontext. This
context is used for tuplestore. But when this function is called from
WindowAgg_Aggregates context - someone drops all child context every
iteration, and
2010/8/19 Pavel Stehule :
> Hello
>
> I am sending a prototype implementation of functions median and
> percentile. This implementation is very simple and I moved it to
> contrib for this moment - it is more easy maintainable. Later I'll
> move it to core.
I've reviewed this patch.
* The patch ca
David Fetter writes:
> On Thu, Aug 19, 2010 at 01:25:36PM -0400, Tom Lane wrote:
>> A name like "arithmetic_median" seems much less likely to get
>> blindsided by future standardization.
> Yep.
OTOH, if Pavel's right that Oracle already has an aggregate named
median(), it seems quite unlikely th
Pavel Stehule wrote:
> I looked there and Oracle11g use "median" in common sense.
As does Sybase IQ. FWIW, Excel spreadsheets do, too.
The chance of the SQL committee picking some other meaning for bare
MEDIAN seems vanishingly small; although I have to grant that with
only Oracle and Sybas
On Thu, Aug 19, 2010 at 01:25:36PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote:
> >> http://www.merriam-webster.com/dictionary/median
> >>
> >> If you do a google search for "median" and poke around, you'll find
> >> many places
2010/8/19 David Fetter :
> On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote:
>> David Fetter wrote:
>>
>> > Median may be useful, but we pretty much can't just call it
>> > "median." Instead, we need to call it something like "left_median"
>> > or "arithmetic_median."
>>
>> I think i
2010/8/19 David Fetter :
> On Thu, Aug 19, 2010 at 12:49:45PM -0400, Robert Haas wrote:
>> On Thu, Aug 19, 2010 at 11:33 AM, Tom Lane wrote:
>> > Greg Stark writes:
>> >> On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule
>> >> wrote:
>> >>> I am sending a prototype implementation of functions med
David Fetter writes:
> On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote:
>> http://www.merriam-webster.com/dictionary/median
>>
>> If you do a google search for "median" and poke around, you'll find
>> many places where this is the only definition mentioned; the others
>> seem to be
On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote:
> David Fetter wrote:
>
> > Median may be useful, but we pretty much can't just call it
> > "median." Instead, we need to call it something like "left_median"
> > or "arithmetic_median."
>
> I think it would be reasonable, and per
David Fetter wrote:
> Median may be useful, but we pretty much can't just call it
> "median." Instead, we need to call it something like "left_median"
> or "arithmetic_median."
I think it would be reasonable, and perhaps preferable, to use just
"median" for the semantics described in most dict
On Thu, Aug 19, 2010 at 12:49:45PM -0400, Robert Haas wrote:
> On Thu, Aug 19, 2010 at 11:33 AM, Tom Lane wrote:
> > Greg Stark writes:
> >> On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule
> >> wrote:
> >>> I am sending a prototype implementation of functions median and
> >>> percentile. This i
On Thu, Aug 19, 2010 at 11:33 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule
>> wrote:
>>> I am sending a prototype implementation of functions median and
>>> percentile. This implementation is very simple and I moved it to
>>> contrib for this momen
Greg Stark writes:
> On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule
> wrote:
>> I am sending a prototype implementation of functions median and
>> percentile. This implementation is very simple and I moved it to
>> contrib for this moment - it is more easy maintainable. Later I'll
>> move it to
On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule wrote:
> I am sending a prototype implementation of functions median and
> percentile. This implementation is very simple and I moved it to
> contrib for this moment - it is more easy maintainable. Later I'll
> move it to core.
So if the entire resu
Hello
I am sending a prototype implementation of functions median and
percentile. This implementation is very simple and I moved it to
contrib for this moment - it is more easy maintainable. Later I'll
move it to core.
These functions are relative simple, there are not barrier for
implementation
88 matches
Mail list logo
