Bruce Momjian wrote:
I have tested this patch but it generates regression failures.
There was some code drift, so I am attaching an updated version of the
patch, and the regression diffs. The 'four' column is an 'int4' so my
guess is that somehow the wrong aggregate is being called.
Good
Mark Kirkwood wrote:
Bruce Momjian wrote:
I have tested this patch but it generates regression failures.
There was some code drift, so I am attaching an updated version of the
patch, and the regression diffs. The 'four' column is an 'int4' so my
guess is that somehow the wrong
Patch applied. Thanks.
---
Mark Kirkwood wrote:
Bruce Momjian wrote:
I have tested this patch but it generates regression failures.
There was some code drift, so I am attaching an updated version of the
patch,
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Neil Conway wrote:
On Fri, 2006-11-24 at 11:08 +1300, Mark Kirkwood wrote:
- Modifies do_numeric_accum to have an extra bool parameter and does not
calc sumX2 when it is false.
I think it would be clearer to reorganize this function slightly, and
have only a single branch on useSumX2. On
Neil Conway wrote:
(it is still slower than doing sum/count - possibly due to the
construct/deconstruct overhead of the numeric transition array).
This would indeed be worth profiling. If it turns out that array
overhead is significant, I wonder if we could use a composite type for
the
So, if I understand this correctly, we're calling Alloc and ContextAlloc 10
times for every row being summed?
There are approx 10M rows and the profile snippet below shows 100M calls to
each of those.
- Luke
On 11/24/06 4:46 PM, Mark Kirkwood [EMAIL PROTECTED] wrote:
time seconds
Luke Lonergan wrote:
So, if I understand this correctly, we're calling Alloc and ContextAlloc 10
times for every row being summed?
There are approx 10M rows and the profile snippet below shows 100M calls to
each of those.
Unless I've accidentally run gprof on the profile output for a 100M
Mark Kirkwood wrote:
Luke Lonergan wrote:
So, if I understand this correctly, we're calling Alloc and
ContextAlloc 10
times for every row being summed?
There are approx 10M rows and the profile snippet below shows 100M
calls to
each of those.
Unless I've accidentally run gprof on the
On Fri, 2006-11-24 at 11:08 +1300, Mark Kirkwood wrote:
- Modifies do_numeric_accum to have an extra bool parameter and does not
calc sumX2 when it is false.
I think it would be clearer to reorganize this function slightly, and
have only a single branch on useSumX2. On first glance it isn't
Neil Conway [EMAIL PROTECTED] writes:
On Fri, 2006-11-24 at 11:08 +1300, Mark Kirkwood wrote:
- Modifies do_numeric_accum to have an extra bool parameter and does not
calc sumX2 when it is false.
I think it would be clearer to reorganize this function slightly, and
have only a single branch
11 matches
Mail list logo
