Thread: build array of composites in SPI

Trying to formulate a good strategy for $subject.  The code is
performance critical.

The composite type is simple: (text, text), that needs to be routed to
function call in array form.  The #elements in the array is small,
generally less than 10.

The approach I have now is this:
1) look up the oid for the composite and prepare tupledesc:
  1a) TypeGetTupleDesc
  2b) BlessTupleDesc

2) build the composite via:
  2a) TupleDescGetAttInMetadata
  2b) BuildTupleFromCStrings
  2c) get datum/HeapTupleGetDatum

3) repeat to 2 until I have a Datum for each tuple

4) construct_array(datums, ndatums, comp_oid, -1, false, false)

5) PointerGetDatum directly on the ArrayType to get the oid to pass to SPI_execp

Does this look reasonable?

merlin

Merlin Moncure <mmoncure@gmail.com> writes:
> 2) build the composite via:
>   2a) TupleDescGetAttInMetadata
>   2b) BuildTupleFromCStrings
>   2c) get datum/HeapTupleGetDatum

If it's performance critical, you might want to avoid the extra overhead
of the AttInMetadata API.  Especially if you know the column datatypes
ahead of time, and even more especially if you have the values in datum
rather than C-string form.  Consider using heap_form_tuple directly.

            regards, tom lane

On Tue, Nov 17, 2009 at 1:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> 2) build the composite via:
>>   2a) TupleDescGetAttInMetadata
>>   2b) BuildTupleFromCStrings
>>   2c) get datum/HeapTupleGetDatum
>
> If it's performance critical, you might want to avoid the extra overhead
> of the AttInMetadata API.  Especially if you know the column datatypes
> ahead of time, and even more especially if you have the values in datum
> rather than C-string form.  Consider using heap_form_tuple directly.

right...makes sense.  converted.  one last question: can you save off
the blessed TupleDesc (that is, make it static) between invocations of
the function (I'm not worried about it changing)?

merlin

Merlin Moncure <mmoncure@gmail.com> writes:
> right...makes sense.  converted.  one last question: can you save off
> the blessed TupleDesc (that is, make it static) between invocations of
> the function (I'm not worried about it changing)?

You could probably get away with copying it into some long-term memory
context.  Once you've blessed it the record typmod should remain the
same for the rest of the session.

If you're feeling bloody-minded you could remember the pointer returned
by lookup_rowtype_tupdesc(), but that strikes me as assuming too much
about the behavior of typcache.c.

            regards, tom lane

On Tue, Nov 17, 2009 at 2:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> right...makes sense.  converted.  one last question: can you save off
>> the blessed TupleDesc (that is, make it static) between invocations of
>> the function (I'm not worried about it changing)?
>
> You could probably get away with copying it into some long-term memory
> context.  Once you've blessed it the record typmod should remain the
> same for the rest of the session.
>
> If you're feeling bloody-minded you could remember the pointer returned
> by lookup_rowtype_tupdesc(), but that strikes me as assuming too much
> about the behavior of typcache.c.

Everything works! fantastic!  Thanks again!

Just an idle thought:
Dealing with the backend api is always a little rough the first time
out.  It's an awfully big job, but ISTM that the C language backend
api could use some expansion.  Perhaps it could get it's own chapter,
with sections for SPI, Datums, triggers, composites, arrays, etc.
"34.8 C-Language Functions" is overlong and not very well organized
IMO.  I certainly don't have time to work on ATM though.

merlin