From: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Surfacing qualifiers |
Date: | 2008-03-28 10:17:18 |
Message-ID: | 47ECC5AE.50205@wildenhain.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> 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 any real improvement in the situation will require exposing
> remote tables as a concept understood by the planner, complete
> with ways to obtain index and statistical information at plan time.
> After suitable decisions about join strategy and so forth, we'd
> wind up with a plan containing a "RemoteTableScan" node which
I'd like to point out that Remote* might be a bit to narrow because
its also a general potential for SRF functions (e.g. any virtual table
construction). Would certainly be nice if we had a as general approach
as possible.
Cheers
Tino
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-03-28 11:26:54 | Re: Commitfest patches |
Previous Message | NikhilS | 2008-03-28 10:07:18 | Re: Problem identifying constraints which should not be inherited |