diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2012-04-04 18:39:08 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2012-04-04 18:39:08 -0400 |
commit | 6f922ef88e43b3084cdddf4b5ffe525a00896a90 (patch) | |
tree | 028b9b7b63eb0b9d39a08367de85cce9e5db6c65 /src/backend/utils/adt/pgstatfuncs.c | |
parent | 92785dac2ee7026948962cd61c4cd84a2d052772 (diff) | |
download | postgresql-6f922ef88e43b3084cdddf4b5ffe525a00896a90.tar.gz postgresql-6f922ef88e43b3084cdddf4b5ffe525a00896a90.zip |
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
Diffstat (limited to 'src/backend/utils/adt/pgstatfuncs.c')
0 files changed, 0 insertions, 0 deletions