Kyle <[EMAIL PROTECTED]> writes:
> This worked great until I put a real big file in (about 5M). Then, when
> I tried to fetch the file, it seemed really slow (about 60 seconds). I
> tried reassembling the file in the frontend instead and my time dropped
> to about 6 seconds using this TCL fragment (mpg::qlist is an interface
> to pg_exec that returns a list of tuples):
> The only difference I can identify is whether the re-assembly TCL code
> is running as a procedural language (backend) or in the frontend.
> Anyone have any idea why the difference is so dramatic?
I happened to have handy a 7.1 backend compiled for profiling, so I
looked into this a little. I confirm that this seems unreasonably slow.
As near as I can tell, 98% of the backend runtime is being spent in
strlen() and strcpy() invoked from Tcl_SetResult invoked from Tcl_Eval
invoked from the per-result-tuple loop in pltcl_SPI_exec. Apparently,
all this is happening because Tcl_Eval thinks it needs to make the
result of the append command available for its caller. I changed the
inner loop to
spi_exec -array d "select data from pg_largeobject where
loid = $1 order by pageno" {
append odata $d(data);
set z z
}
and voila, the runtime dropped to something reasonable.
So, yes, it would seem that some care in the inner loop of
pltcl_SPI_exec would help a lot. It'd be worth if'defing the Tcl_Eval
call there to use a new-style call when using Tcl 8. (This could also
avoid repetitive parsing of the loop body.) Might want to think about
the same for the Tcl function as a whole, too.
I was also distressed to notice that pltcl_set_tuple_values does a LOT
of repetitive work --- it should be fixed so that the syscache and
function lookups are done only once, not once per tuple.
regards, tom lane
