On Fri, Sep 15, 2006 at 06:50:37PM +0100, Gregory Stark wrote:
> With a CHAR(1) and CASH style numeric substitute we won't have 25-100%
> performance lost on the things that would fit in 1-4 bytes. And with the
> variable sized varlena header we'll limit to 25% at worst and 1-2% usually the
> performance drain due to wasted space on larger data.
I wonder how much of the benefit will be eaten by alignment. I think
it'd be great if we rearrange the fields in a tuple to minimize
alignment, but that logical field order patch has been and gone and the
issues havn't changed.
There's also slack at the end of pages.
> Doing better would require a complete solution to data types that can
> understand how large they are based on their typmod. That would imply more
> dramatic solutions like I mused about involving passing around structures that
> contain the Datum as well as the attlen or atttypmod. The more I think about
> these ideas the more I think they may have merit but they would be awfully
> invasive and require more thought.
Whatever the solution is here, the same logic will have to apply to
extracting Datums out of tuples. If you want the 7th column in a tuple,
you have to find the lengths of all the previous datums first.
Good summary though, probably worth putting on the wiki so next time we
don't have to search the archives.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
