On 2013-06-20 13:45:24 +0800, Craig Ringer wrote:
> On 06/12/2013 07:51 PM, Andres Freund wrote:
> > On 2013-06-12 19:47:46 +0800, Craig Ringer wrote:
> >> On 06/12/2013 05:55 PM, Greg Stark wrote:
> >>> On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> >>>> The main thing I'm wondering is how/if to handle backward compatibility with
> >>>> the existing NUMERIC and its DECIMAL alias
> >>> If it were 100% functionally equivalent you could just hide the
> >>> implementation internally. Have a bit that indicates which
> >>> representation was stored and call the right function depending.
> >> That's what I was originally wondering about, but as Tom pointed out it
> >> won't work. We'd still need to handle scale and precision greater than
> >> that offered by _Decimal128 and wouldn't know in advance how much
> >> scale/precision they wanted to preserve. So we'd land up upcasting
> >> everything to NUMERIC whenever we did anything with it anyway, only to
> >> then convert it back into the appropriate fixed size decimal type for
> >> storage.
> > Well, you can limit the "upcasting" to the cases where we would exceed
> > the precision.
> How do you determine that for, say, DECIMAL '4'/ DECIMAL '3'? Or
> sqrt(DECIMAL '2') ?
Well, the suggestion above was not to actually implement them as
separate types. If you only store the precision inside the Datum you can
limit the upcasting to whatever you need.
> I think a good starting point would be to use the Intel and IBM
> libraries to implement basic DECIMAL32/64/128 to see if they perform
> better than the gcc builtins tested by Pavel by adapting his extension.
Another good thing to investigate early on is whether there's actually a
need for the feature outside complying to standards.
> >> Pretty pointless, and made doubly so by the fact that if we're
> >> not using a nice fixed-width type and have to support VARLENA we miss
> >> out on a whole bunch of performance benefits.
> > I rather doubt that using a 1byte varlena - which it will be for
> > reasonably sized Datums - will be a relevant bottleneck here. Maybe if
> > you only have 'NOT NULL', fixed width columns, but even then...
> That's good to know - if I've overestimated the cost of using VARLENA
> for this, that's really quite good news.
From what I remember seing in profiles the biggest overhead is that the
short varlenas (not long ones though) frequently need to be copied
around so they are placed at an aligned address. I think with some care
numeric.c could be made to avoid that for the most common cases which
should speed up things nicely.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services