Re: Reducing the overhead of NUMERIC data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing the overhead of NUMERIC data
Date
Msg-id 28946.1130884835@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reducing the overhead of NUMERIC data  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Reducing the overhead of NUMERIC data
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> You are proposing a fourth type, say VARLENA2 which looks a lot like a
> verlena but it's not. I think the shear volume of code that would need
> to be checked is huge. Also, things like pg_attribute would need
> changing because you have to represent this new state somehow.

It wouldn't be an impossible amount of code --- for precedent see back
when we made cstring into a full-fledged datatype (cstring is already
a fourth option in your list BTW).  That patch wasn't all that large IIRC.
The issue in my mind is the performance implications of adding an
additional case to places that are already hotspots.  There were
compelling functional reasons to pay that price to make cstring work,
but "save 2 bytes per numeric" doesn't seem like it rises to that level.
Maybe if we had a few other datatypes that could also use the feature.
[ thinks... ]  inet/cidr comes to mind but I don't see any others.
The case seems a bit weak :-(
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Reducing the overhead of NUMERIC data
Next
From: Simon Riggs
Date:
Subject: Re: Reducing the overhead of NUMERIC data