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 21:50:23 |
Message-ID: | 1130968223.8300.1810.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:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > I wasn't trying to claim the bit assignment made sense. My point was
> > that the work to mangle the two fields together to make it make sense
> > looked like it would take more CPU (since the standard representation of
> > signed integers is different for +ve and -ve values). It is the more CPU
> > I'm worried about, not the wasted bits on the weight.
>
> I think that's purely hypothetical. The existing representation, as
> well as the one you propose, both require shift-and-mask operations
> to pull the fields out of the packed format. The format I'm suggesting
> would require some different shift-and-mask operations. As a first
> approximation it'd be a wash, and any actual differences would be
> CPU-specific enough that we shouldn't put a whole lot of weight on the
> point. (C compilers tend to be fairly bright about optimizing field
> extraction operations.)
OK
> Moreover, you've forgotten the basic gating factor here, which is
> whether such a proposal will get accepted at all. Reducing the
> available range from 1000 digits to 255 might pass without too much
> objection, but dropping it down another factor of 4 to 63 starts to
> bring it uncomfortably close to mattering to people.
>
> [ 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.
Well, that certainly is obscure, I'll give you that. 308 huh?
The middle ground between 64 and 308 is somewhere around 255, yes? :-)
I'll get on it. Including Catch-308.
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-11-02 21:51:47 | Re: pg_restore [archiver] file offset in dump file is too |
Previous Message | Edward Di Geronimo Jr. | 2005-11-02 21:49:29 | ODBC link to other databases |
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-11-02 22:51:54 | Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags |
Previous Message | Martijn van Oosterhout | 2005-11-02 20:42:42 | Re: Reducing the overhead of NUMERIC data |