You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hawq.apache.org by "Shivram Mani (JIRA)" <ji...@apache.org> on 2016/07/22 18:23:20 UTC
[jira] [Comment Edited] (HAWQ-944) Numutils.c: pg_ltoa and pg_itoa
functions allocate unnecessary amount of bytes
[ https://issues.apache.org/jira/browse/HAWQ-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389985#comment-15389985 ]
Shivram Mani edited comment on HAWQ-944 at 7/22/16 6:22 PM:
------------------------------------------------------------
Yes, it does look like we are over allocating bytes
was (Author: shivram):
Nice catch on the patch !
> Numutils.c: pg_ltoa and pg_itoa functions allocate unnecessary amount of bytes
> ------------------------------------------------------------------------------
>
> Key: HAWQ-944
> URL: https://issues.apache.org/jira/browse/HAWQ-944
> Project: Apache HAWQ
> Issue Type: Improvement
> Components: Core
> Reporter: Kavinder Dhaliwal
> Assignee: Kavinder Dhaliwal
> Priority: Minor
> Fix For: 2.0.1.0-incubating
>
>
> The current implementations of {{pg_ltoa}} and {{pg_itoa}} allocate a 33 byte char array and set the input pointer to that array. This is far too many bytes than needed to translate an int16 or int32 to a string
> int32 -> 10 bytes maximum + 1 sign bit + '\0' = 12 bytes
> int16 -> 5 bytes maximum + 1 sign bit + '\0' = 7 bytes
> When HAWQ/Greenplum forked from Postgres the two functions simply delegated to {{sprintf}} so an optimization was introduced that involved the 33 byte solution. Postgres itself implemented these functions in commit https://github.com/postgres/postgres/commit/4fc115b2e981f8c63165ca86a23215380a3fda66 that require a 12 byte maximum char pointer.
> This is a minor improvement that can be made to the HAWQ codebase and it's relatively little effort to do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)