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

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Of course the obvious way of getting rid of the parser overhead is not
> to parse everytime --- viz, to use prepared statements.

I think this would be nice to have too... On a similar note (I think
anyway) I wasn't able to find any functions for bulk dumps into memory
space from a select statement. This would probably be alot more work
but I find it very useful with other databases I work on (mainly
Oracle).

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.

The same is true for 'insert' statements, in reverse, of course. This
avoids alot of unnecssary parsing and type conversion (where possible).
This does give more work to the library since it has to be able to do
type conversions in some cases where the database type and the user
requested type differ.

Thanks,
Stephen