David Fetter <[EMAIL PROTECTED]> writes: > What happens now with dblink is that the remote table (more generally, > the output of a fixed query) gets materialized into memory in its > entirety, and if it's bigger than what's available, it will crash the > backend or worse.
This is utter nonsense. It gets put into a tuplestore which is entirely capable of spilling to disk. Slow, yes, but crashing is a lie. > That happens because functions do not have any > access to the predicates with which they were called, so the current > workaround is to pass the predicates manually and then cast. dblink is not a suitable framework for improving that situation. Maybe someday we'll have a proper implementation of SQL/MED ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers