Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Reducing the overhead of NUMERIC data

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>,"Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org,pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Reducing the overhead of NUMERIC data
Date: 2005-11-03 00:12:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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.

If we were willing to invent the "varlena2" datum format then we could
save four bytes per numeric, plus reduce numeric's alignment requirement
from int to short which would probably save another byte per value on
average.  I'm not sure that that's worth doing if numeric and inet are
the only beneficiaries, but it might be.

From a speed perspective the only thing favoring UNKNOWNNUMERIC is the
possibility for saving some conversion operations when the grammar's
initial guess about datatype is wrong.  That's probably pretty marginal
though.  I was thinking of it more as a vehicle for helping us clean up
the type-assignment behavior some more.  The example I have in my notes
is that "float4col = 1.8" is certain to fail since 1.8 will be taken as
float8, not float4, and then you have precision mismatch problems.
You can make it work by quoting: "float4col = '1.8'" but that's surely
pretty ugly.  If the constant were initially UNKNOWNNUMERIC then it
would end up as float4 without that hack.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2005-11-03 08:27:56
Subject: Re: Reducing the overhead of NUMERIC data
Previous:From: Tom LaneDate: 2005-11-02 23:45:21
Subject: Re: Assert failure found in 8.1RC1

pgsql-patches by date

Next:From: Tom LaneDate: 2005-11-03 02:55:11
Subject: Re: pgcrypto doc polish
Previous:From: Neil ConwayDate: 2005-11-02 23:57:39
Subject: Re: [PATCHES] Partitioning docs

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group