Re: [PATCHES] Avg performance for int8/numeric

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Luke Lonergan" <llonergan(at)greenplum(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Avg performance for int8/numeric
Date: 2006-11-26 17:14:36
Message-ID: 19371.1164561276@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Sat, 2006-11-25 at 18:57 +1300, Mark Kirkwood wrote:
>> Also Neil suggested investigating using a single composite type
>> {int8,
>> numeric} for the {N,sum(X)} transition values. This could well be a
>> faster way to do this (not sure how to make it work yet... but it
>> sounds
>> promising...).

> If that is true it implies that any fixed length array is more expensive
> than using a composite type.

Not sure how you derived that conclusion from this statement, but it
doesn't appear to me to follow at all. The reason for Neil's suggestion
was to avoid using numeric arithmetic to run a simple counter, and the
reason that this array stuff is expensive is that the array *components*
are variable-length, which is something that no amount of array
redesigning will eliminate.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeroen T. Vermeulen 2006-11-26 18:44:50 Re: "Optional ident" authentication
Previous Message Andrew Dunstan 2006-11-26 17:07:57 Re: [CORE] RC1 blocker issues

Browse pgsql-patches by date

  From Date Subject
Next Message Mark Kirkwood 2006-11-26 22:08:54 Re: [PATCHES] Avg performance for int8/numeric
Previous Message Simon Riggs 2006-11-26 16:41:32 Re: [PATCHES] Avg performance for int8/numeric