Tom Lane wrote:
Well, yeah, because the first thing it does is pg_detoast_datum. Just as a cross-check, try changing it to copy the value without forcibly detoasting --- I'll bet it's still slow then.
Yeah, that appears to be exactly the case. After some grepping through various header files I came up with this alternative:
PG_FUNCTION_INFO_V1(LWGEOM_mcatest); Datum LWGEOM_mcatest(PG_FUNCTION_ARGS) { struct varlena *pgl = PG_GETARG_RAW_VARLENA_P(0); void *mem; // Copy somewhere else mem = palloc(VARSIZE_EXTERNAL(pgl)); memcpy(mem, pgl, VARSIZE_EXTERNAL(pgl)); PG_RETURN_POINTER(mem); } ...and of course, this now takes the slower runtime of 2.5s. ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers