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/HeapTupleGetDatumIf 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