]> granicus.if.org Git - postgresql/commit
Improve efficiency of dblink by using libpq's new row processor API.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 4 Apr 2012 22:39:08 +0000 (18:39 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 4 Apr 2012 22:39:08 +0000 (18:39 -0400)
commit6f922ef88e43b3084cdddf4b5ffe525a00896a90
tree028b9b7b63eb0b9d39a08367de85cce9e5db6c65
parent92785dac2ee7026948962cd61c4cd84a2d052772
Improve efficiency of dblink by using libpq's new row processor API.

This patch provides a test case for libpq's row processor API.
contrib/dblink can deal with very large result sets by dumping them into
a tuplestore (which can spill to disk) --- but until now, the intermediate
storage of the query result in a PGresult meant memory bloat for any large
result.  Now we use a row processor to convert the data to tuple form and
dump it directly into the tuplestore.

A limitation is that this only works for plain dblink() queries, not
dblink_send_query() followed by dblink_get_result().  In the latter
case we don't know the desired tuple rowtype soon enough.  While hack
solutions to that are possible, a different user-level API would
probably be a better answer.

Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane
contrib/dblink/dblink.c
doc/src/sgml/dblink.sgml