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
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
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 text...
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, it would be
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).
Thinko there ... I
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 as the
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 think
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 other
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, 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
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 about
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
12 matches
Mail list logo
