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 q
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, n
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 =
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
b
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
marg
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.
AFAIC
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 availabl
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.
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
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
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
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
src/back
12 matches
Mail list logo
