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
> >
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 wro
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 cat
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.
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.
---
Ma
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 prof
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 row
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 se
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 trans
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 fir
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Mark Kirkwood wrote:
> Avg performance for these two datatypes can be improved by *not*
> calculating the sum of squ
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 singl
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
13 matches
Mail list logo
