Re: Reducing the overhead of NUMERIC data

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reducing the overhead of NUMERIC data
Date: 2005-11-03 16:36:45
Message-ID: 436A3C9D.9030603@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Simon Riggs wrote:

>On Wed, 2005-11-02 at 19:12 -0500, Tom Lane wrote:
>
>
>>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>
>>>Could someone please quantify how much bang we might get for what seems
>>>like quite a lot of bucks?
>>>I appreciate the need for speed, but the saving here strikes me as
>>>marginal at best, unless my instincts are all wrong (quite possible)
>>>
>>>
>>Two bytes per numeric value is not a lot, agreed.
>>
>>
>
>I'm optimising for Data Warehousing. If you have a very large table with
>a higher proportion of numerics on it, then your saving can be >5% of
>tablesize which could be very useful. For the general user, it might
>produce less benefit, I accept.
>
>
>

Well, it could also be argued that DW apps could often get away with
using floating point types, even where the primary source needs to be in
fixed point for accuracy, and that could generate lots of savings in
speed and space. But I guess everybody gets to make their own choices.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-11-03 17:11:40 pgsql: Rename the members of CommandDest enum so they don't collide with
Previous Message Simon Riggs 2005-11-03 16:22:42 Re: Reducing the overhead of NUMERIC data

Browse pgsql-patches by date

  From Date Subject
Next Message mark 2005-11-03 17:28:02 Re: Reducing the overhead of NUMERIC data
Previous Message Simon Riggs 2005-11-03 16:22:42 Re: Reducing the overhead of NUMERIC data