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

Re: [HACKERS] Reducing the overhead of NUMERIC data

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "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-02 22:56:17
Message-ID: 1130972177.8300.1827.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Wed, 2005-11-02 at 15:09 -0500, Tom Lane wrote:

> [ thinks for a moment... ]  Actually, neither proposal is going to get
> off the ground, because the parser's handling of numeric constants is
> predicated on the assumption that type NUMERIC can handle any valid
> value of FLOAT8, and so we can get away with converting to NUMERIC on
> sight and then coercing to float later if parse analysis finds out the
> constant should be float.  If the dynamic range of NUMERIC is less than
> 10^308 then this fails.  So we have to find another bit somewhere, or
> the idea is dead in the water.

We convert a Value node to a Const in
backend/parser/parse_node.c:make_const

It seems straightforward enough to put in an additional test, similar to
the ones already there so that if its too big for a decimal we make it a
float straight away - only a float can be that big in that case. After
that I can't really see what the problem is?

There is only a single call where numeric_float8() is called anywhere in
the code, which is during selectivity calculations. In that case we
actually call numeric_float8_no_overflow(). If its a FLOAT8OID, then we
can simply avoid the conversion, since it already would be one.

Can you explain further? Thanks,

Best Regards, Simon Riggs




In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-11-02 23:12:37
Subject: Re: [HACKERS] Reducing the overhead of NUMERIC data
Previous:From: Tom LaneDate: 2005-11-02 22:53:48
Subject: Re: 8.1RC1 fails to build on OS X (10.4)

pgsql-patches by date

Next:From: Tom LaneDate: 2005-11-02 23:12:37
Subject: Re: [HACKERS] Reducing the overhead of NUMERIC data
Previous:From: Jim C. NasbyDate: 2005-11-02 22:51:54
Subject: Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags

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