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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-02 23:12:37 | Re: [HACKERS] Reducing the overhead of NUMERIC data |
Previous Message | Tom Lane | 2005-11-02 22:53:48 | Re: 8.1RC1 fails to build on OS X (10.4) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-02 23:12:37 | Re: [HACKERS] Reducing the overhead of NUMERIC data |
Previous Message | Jim C. Nasby | 2005-11-02 22:51:54 | Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags |