Petr Jelinek writes:
> On 07/09/14 21:09, Andres Freund wrote:
>> On 2014-09-07 15:05:35 -0400, Tom Lane wrote:
>>> I think the main remaining issue is that we don't have consensus on
>>> the function name AFAICT. I'm okay with using width_bucket(), as
>>> is done in the latest patch, but there w
On 07/09/14 21:09, Andres Freund wrote:
On 2014-09-07 15:05:35 -0400, Tom Lane wrote:
I think the main remaining issue is that we don't have consensus on
the function name AFAICT. I'm okay with using width_bucket(), as
is done in the latest patch, but there were objections ...
Just reread tha
On 2014-09-07 15:05:35 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Tom, are you planning to take this one?
>
> Yeah, I already looked at it once, so will take it.
Cool.
> I think the main remaining issue is that we don't have consensus on
> the function name AFAICT. I'm okay with using
Andres Freund writes:
> Tom, are you planning to take this one?
Yeah, I already looked at it once, so will take it.
I think the main remaining issue is that we don't have consensus on
the function name AFAICT. I'm okay with using width_bucket(), as
is done in the latest patch, but there were ob
On 2014-09-07 20:45:38 +0200, Pavel Stehule wrote:
> 2014-09-07 14:29 GMT+02:00 Petr Jelinek :
> > Ah yeah I forgot about those, fixed in attached patch.
> ok
>
> It is ready for commit
Tom, are you planning to take this one?
Greetings,
Andres Freund
--
Andres Freund htt
2014-09-07 14:29 GMT+02:00 Petr Jelinek :
> On 04/09/14 21:16, Pavel Stehule wrote:
>
>>
>> I did a review of last patch
>>
>
> Thanks
>
>
>> I found only one issue - float8 path has no own test in regress tests.
>> When this issue will be fixed, I will mark this patch as ready for commit
>>
>>
>
On 04/09/14 21:16, Pavel Stehule wrote:
I did a review of last patch
Thanks
I found only one issue - float8 path has no own test in regress tests.
When this issue will be fixed, I will mark this patch as ready for commit
Ah yeah I forgot about those, fixed in attached patch.
--
Petr Je
Hi
I did a review of last patch
1. There is no problem with patching
2. compilation and doc compilation without warnings and issues.
3. code is clean, respects Postgres coding rules and is well documented -
it is slightly modified Tom's version with float8 optimization
4. The name with_bucket is
On 01/09/14 01:42, Tom Lane wrote:
BTW, was there a reason for not noticing the case of exact match in
the search loop, and falling out early? As it stands the code will
reliably choose the leftmost match if there are multiple equal items
in the search array, but do we care about such cases?
On Sun, Aug 31, 2014 at 7:48 PM, Tom Lane wrote:
> David G Johnston writes:
> > Since "bucket" is the 'verb' here (in this specific case meaning "lookup
> the
> > supplied value in the supplied bucket definition") and "width" is a
> modifier
> > (the bucket specification describes an equal-width
David G Johnston writes:
> Since "bucket" is the 'verb' here (in this specific case meaning "lookup the
> supplied value in the supplied bucket definition") and "width" is a modifier
> (the bucket specification describes an equal-width structure) I suggest
> "literal_bucket(val, array[])" such tha
Petr Jelinek writes:
> On 31/08/14 22:33, Tom Lane wrote:
>> Petr Jelinek writes:
>>> The difference between my generic and Tom's generic is because Tom's is
>>> slowed down by the deconstruct_array.
>> Meh. It looked to me like your version would have O(N^2) performance
>> problems from comput
Simon Riggs wrote
> width_bucket() seems to refer to an equal-width binning process. The
> function being discussed here is a generic mechanism, the boundaries
> of which could have been decided using equal-frequency or other
> mechanisms. Using the word "width" in those contexts could be
> confusi
On 31/08/14 22:33, Tom Lane wrote:
Petr Jelinek writes:
On 30/08/14 19:24, Tom Lane wrote:
I wasn't terribly happy about that either. I still think we should
reduce this to a single polymorphic function, as in the attached.
I did try to write generic function very similar to what you wrote
On 31 August 2014 20:44, Gavin Flower wrote:
> On 01/09/14 06:00, Tom Lane wrote:
>>
>> Simon Riggs writes:
>>>
>>> Suggest discretize() as a much more informative name. The other names
>>> will be overlooked by anybody that doesn't already know what to look
>>> for.
>>
>> I did not like that ide
Petr Jelinek writes:
> On 30/08/14 19:24, Tom Lane wrote:
>> I wasn't terribly happy about that either. I still think we should
>> reduce this to a single polymorphic function, as in the attached.
> I did try to write generic function very similar to what you wrote but
> discarded it because of
On 30/08/14 19:24, Tom Lane wrote:
Pavel Stehule writes:
1. I am thinking so reduction to only numeric types is not necessary -
although we can live without it - but there are lot of non numeric
categories: chars, date, ...
I wasn't terribly happy about that either. I still think we should
r
On 01/09/14 06:00, Tom Lane wrote:
Simon Riggs writes:
Suggest discretize() as a much more informative name. The other names
will be overlooked by anybody that doesn't already know what to look
for.
I did not like that idea to begin with, but it's growing more attractive.
In particular, I thin
Simon Riggs writes:
> Suggest discretize() as a much more informative name. The other names
> will be overlooked by anybody that doesn't already know what to look
> for.
I did not like that idea to begin with, but it's growing more attractive.
In particular, I think it would be unique enough that
On 30 August 2014 18:24, Tom Lane wrote:
>> 3. I am thinking about name - I don't think so varwidth_bucket is correct
>> -- in relation to name "width_bucket" ... what about "range_bucket" or
>> "scope_bucket" ?
>
> Neither of those seem like improvements from here. I agree with the
> objections
Pavel Stehule writes:
> 1. I am thinking so reduction to only numeric types is not necessary -
> although we can live without it - but there are lot of non numeric
> categories: chars, date, ...
I wasn't terribly happy about that either. I still think we should
reduce this to a single polymorphi
Hi
I am looking to your last patch and I have a few questions, notes
1. I am thinking so reduction to only numeric types is not necessary -
although we can live without it - but there are lot of non numeric
categories: chars, date, ...
2. Still I strongly afraid about used searching method - the
Hi,
I finally had some time to get back to this.
I attached version3 of the patch which "fixes" Tom's complaint about
int8 version by removing the int8 version as it does not seem necessary
(the float8 can handle integers just fine).
This patch now basically has just one optimized function f
On 16 July 2014 20:35, Pavel Stehule wrote:
>
>
>
> 2014-07-16 10:04 GMT+02:00 Petr Jelinek :
>
>> On 08/07/14 02:14, Tom Lane wrote:
>>>
>>> Petr Jelinek writes:
here is a patch implementing varwidth_bucket (naming is up for
discussion) function which does binning with variable bu
On 08/07/14 02:14, Tom Lane wrote:
Also, the set of functions provided still needs more thought, because the
resolution of overloaded functions doesn't really work as nicely as all
that.
I am honestly considering just removing special case for int8 for now,
the sql standard width_bucket has on
On 16/07/14 21:35, Pavel Stehule wrote:
The performance difference is about 20% (+/- few depending on the
array size), I don't know if that's bad enough to warrant
type-specific implementation. I personally don't know how to make
the generic implementation much faster than it is n
2014-07-16 10:04 GMT+02:00 Petr Jelinek :
> On 08/07/14 02:14, Tom Lane wrote:
>
>> Petr Jelinek writes:
>>
>>> here is a patch implementing varwidth_bucket (naming is up for
>>> discussion) function which does binning with variable bucket width.
>>>
>>
>> I didn't see any discussion of the namin
On 08/07/14 02:14, Tom Lane wrote:
Petr Jelinek writes:
here is a patch implementing varwidth_bucket (naming is up for
discussion) function which does binning with variable bucket width.
I didn't see any discussion of the naming question in this thread.
I'd like to propose that it should be j
Petr Jelinek writes:
> here is a patch implementing varwidth_bucket (naming is up for
> discussion) function which does binning with variable bucket width.
I didn't see any discussion of the naming question in this thread.
I'd like to propose that it should be just "width_bucket()"; we can
easil
On 17/06/14 16:15, Robert Haas wrote:
On Fri, Jun 13, 2014 at 8:22 PM, Petr Jelinek wrote:
here is a patch implementing varwidth_bucket (naming is up for discussion)
function which does binning with variable bucket width. The use-cases are
same as for width_bucket (=data analytics, mainly histo
On Fri, Jun 13, 2014 at 8:22 PM, Petr Jelinek wrote:
> here is a patch implementing varwidth_bucket (naming is up for discussion)
> function which does binning with variable bucket width. The use-cases are
> same as for width_bucket (=data analytics, mainly histograms), the
> difference is that wi
Hello,
here is a patch implementing varwidth_bucket (naming is up for
discussion) function which does binning with variable bucket width. The
use-cases are same as for width_bucket (=data analytics, mainly
histograms), the difference is that width_bucket uses buckets of same
width but the var
32 matches
Mail list logo
