On Wed, Mar 26, 2008 at 01:21:14PM -0400, Tom Lane wrote:
> David Fetter <david@fetter.org> 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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate