| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Surfacing qualifiers |
| Date: | 2008-03-26 17:21:14 |
| Message-ID: | 29678.1206552074@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)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 ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2008-03-26 17:27:53 | Re: Surfacing qualifiers |
| Previous Message | Kenneth Marshall | 2008-03-26 17:18:50 | Re: [GSoC] Need for advice on improving hash index performance |