Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
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?
The main problem with what you suggest is that it'll fail utterly
on join
Folks,
Neil Conway sent me a patch that sketched out a plan to make quals
visible to functions, and Korry Douglas filled in much of the rest of
what you see attached here. Mistakes are all mine. :)
Random observations:
* It appears I've botched the call to deparse_context_for_plan in
David Fetter wrote:
Folks,
Neil Conway sent me a patch that sketched out a plan to make quals
visible to functions
er, what? Please explain what this means, why it might be useful.
Example(s) would help.
* In PL/Perl, $_TD-{_quals} gets the qualifiers, but they really
should go in
Andrew Dunstan [EMAIL PROTECTED] writes:
David Fetter wrote:
Neil Conway sent me a patch that sketched out a plan to make quals
visible to functions
er, what? Please explain what this means, why it might be useful.
It's utterly useless, because it only exposes a small fraction of the
On Wed, Mar 26, 2008 at 08:31:04AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
Folks,
Neil Conway sent me a patch that sketched out a plan to make quals
visible to functions
er, what? Please explain what this means, why it might be useful.
Example(s) would help.
Right now,
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
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
David Fetter [EMAIL PROTECTED] writes:
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?
The main problem with what you suggest is that it'll fail utterly
on join queries.
AFAICS
David Fetter wrote:
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 :)
I'm still waiting to see an example of where you say this patch is even
On Wed, 2008-03-26 at 14:38 -0400, Andrew Dunstan wrote:
I'm still waiting to see an example of where you say this patch is even
marginally useful.
It's not hard to think of one:
SELECT * FROM remote_table() WHERE x = 5;
Applying the predicate on the remote database (pushing the predicate
On Wed, Mar 26, 2008 at 02:26:41PM -0700, Neil Conway wrote:
On Wed, 2008-03-26 at 14:38 -0400, Andrew Dunstan wrote:
I'm still waiting to see an example of where you say this patch is
even marginally useful.
It's not hard to think of one:
SELECT * FROM remote_table() WHERE x = 5;
In
Neil Conway [EMAIL PROTECTED] writes:
Certainly I agree with Tom that proper SQL/MED support requires
significant support from both the executor and the optimizer. This is
just a quick hack to take advantage of the existing predicate pushdown
logic -- I just thought it was a cute trick, not
12 matches
Mail list logo
