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.
> 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...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services