Re: Parsing speed (was Re: pgstats_initstats() cost)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parsing speed (was Re: pgstats_initstats() cost)
Date: 2003-08-12 20:41:30
Message-ID: 16354.1060720890@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-08-12 20:51:23 Re: Parsing speed (was Re: pgstats_initstats() cost)
Previous Message Tom Lane 2003-08-12 20:37:33 Re: Parsing speed (was Re: pgstats_initstats() cost)