On Wed, Mar 26, 2008 at 01:21:14PM -0400, Tom Lane wrote: > 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 ...
This is intended to be a step or two along the way :) You mentioned in an earlier mail that the information exposed was inadequate. Could you sketch out what information would really be needed and where to find it? Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
