Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2006-10-09 at 12:02 -0400, Tom Lane wrote:
>> It's not clear to me why we have width_bucket operating on numeric and
>> not float8
> I asked about this when I originally implemented width_bucket(), I
> recall[1]. At the time, there was scepticism a
On Mon, 2006-10-09 at 12:02 -0400, Tom Lane wrote:
> It's not clear to me why we have width_bucket operating on numeric and
> not float8
I asked about this when I originally implemented width_bucket(), I
recall[1]. At the time, there was scepticism about whether it was even
worth implementing widt
Jeremy Drake <[EMAIL PROTECTED]> writes:
> I found the function I used before I implemented the C version. It was
> significantly slower, which is why I wrote the C version.
I would imagine that most of the problem is the NUMERIC arithmetic
that's doing.
regards, tom lane
On Mon, Oct 09, 2006 at 03:49:50PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Mon, Oct 09, 2006 at 01:49:37PM -0400, Tom Lane wrote:
> >> This is exactly the slippery slope I don't care to start down.
>
> > I guess I'm confused as to how this is any different from o
On Mon, 9 Oct 2006, Tom Lane wrote:
> It's not clear to me why we have width_bucket operating on numeric and
> not float8 --- that seems like an oversight, if not outright
> misunderstanding of the type hierarchy.
Would that make the below a lot faster?
> But if we had the float8
> version, I th
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Mon, Oct 09, 2006 at 01:49:37PM -0400, Tom Lane wrote:
>> This is exactly the slippery slope I don't care to start down.
> I guess I'm confused as to how this is any different from other
> functions where we've provided multiple input arguments, such
On Mon, Oct 09, 2006 at 01:49:37PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Mon, Oct 09, 2006 at 12:02:12PM -0400, Tom Lane wrote:
> >> ... I think Jeremy's problem would be solved just by applying
> >> the float8 version to "extract(epoch from timestamp)".
>
> Th
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Mon, Oct 09, 2006 at 12:02:12PM -0400, Tom Lane wrote:
>> ... I think Jeremy's problem would be solved just by applying
>> the float8 version to "extract(epoch from timestamp)".
Thinko there ... I meant to type "extract(epoch from interval)".
> Well
On Mon, Oct 09, 2006 at 12:02:12PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Sinte we already have width_bucket, I'd argue this should go in core. If
> > someone's feeling adventurous, there should probably be a double
> > precision version as well. Hrm... and maybe te
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Sinte we already have width_bucket, I'd argue this should go in core. If
> someone's feeling adventurous, there should probably be a double
> precision version as well. Hrm... and maybe text...
It's not clear to me why we have width_bucket operating on
Sinte we already have width_bucket, I'd argue this should go in core. If
someone's feeling adventurous, there should probably be a double
precision version as well. Hrm... and maybe text...
Doesn't the backend already have something like this for calculating
histograms?
On Sun, Oct 08, 2006 at 10
I just came across this code I wrote about a year ago which implements a
function equivilant to width_bucket for timestamps.
I wrote this when I was trying to plot some data over time, and I had more
points than I needed. This function allowed me to create a pre-determined
number of "bins" to ave
12 matches
Mail list logo
