Re: FDW / list of needed columns, WHERE conditions (in PlanForeignScan)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FDW / list of needed columns, WHERE conditions (in PlanForeignScan)
Date: 2012-05-30 04:01:52
Message-ID: 17388.1338350512@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
> Do I need to return only the data in rel->reltargetlist, or should I
> return all the columns (including those in rel->baserestrictinfo)?

> Because AFAIK PostgreSQL will recheck the conditions on the data
> returned from FDW and if I only return the attributes from the
> reltargetlist, the conditions will evaluate to FALSE. Can I prevent the
> recheck somehow e.g. by deleting it from baserestrictinfo?

In 9.1, the FDW doesn't have any control over that, so yeah you have to
include all those columns in the constructed scan tuples. We rejiggered
this in 9.2 so that the FDW could control which baserestrictinfo quals
are evaluated that way. (Of course, it's up to you to be sure you do
somehow check any conditions you remove from the qual list.)

> Also, how is baserestrictinfo related to PlanState.quals? Actually what
> are 'qual conditions'? I see 'qual' is a list of conditions connected by
> AND, but I'm not sure what a 'qual' means. Is that equality?

It's just planner slang for a WHERE condition. The List structure
corresponds to top-level AND structure in WHERE, but otherwise the
elements correspond directly to WHERE expressions.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-30 04:21:33 Re: hash index concurrency
Previous Message Robert Haas 2012-05-30 03:54:13 Re: hash index concurrency