Re: Parsing speed (was Re: pgstats_initstats() cost) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parsing speed (was Re: pgstats_initstats() cost)
Date
Msg-id 16354.1060720890@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parsing speed (was Re: pgstats_initstats() cost)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Parsing speed (was Re: pgstats_initstats() cost)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> You probably know but I'll quickly outline it to point out the
> differences, as I see them, from the 'COPY' ability.  Basically the user
> defines their own C structure and then malloc's an array of them.  The
> user then tells the database the type, offset from start of structure
> and the skip (size of structure) for each column returned by the select
> statement.  The user can then do 'bulk' grabs with a single command into
> the memory space allocated, doing more than one and changing the offsets
> inbetween if more is returned than was initially allocated for.  The
> user can realloc or allocate new segments and do their own handling of
> the segments if they choose.

[shrug]  That seems like a substantial increase in API complexity for
at best marginal performance gains.  What does it gain for the user to
malloc space rather than libpq?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)
Next
From: Tom Lane
Date:
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)