Re: Surfacing qualifiers

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

In response to

Browse pgsql-hackers by date

  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