|From:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: inherit support for foreign tables|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2014/12/23 0:36, Tom Lane wrote:
> Yeah, we need to do something about the PlanRowMark data structure.
> Aside from the pre-existing issue in postgres_fdw, we need to fix it
> to support inheritance trees in which more than one rowmark method
> is being used. That rte.hasForeignChildren thing is a crock, and
> would still be a crock even if it were correctly documented as being
> a planner temporary variable (rather than the current implication that
> it's always valid). RangeTblEntry is no place for planner temporaries.
> The idea I'd had about that was to convert the markType field into a
> bitmask, so that a parent node's markType could represent the logical
> OR of the rowmark methods being used by all its children. I've not
> attempted to code this up though, and probably won't get to it until
> after Christmas. One thing that's not clear is what should happen
> with ExecRowMark.
That seems like a good idea, as parent PlanRowMarks are ignored at runtime.
Aside from the above, I noticed that the patch has a bug in handling
ExecRowMarks/ExecAuxRowMarks for foreign tables in inheritance trees
during the EPQ processing.:-( Attached is an updated version of the
patch to fix that, which has been created on top of , as said before.
|Next Message||Fujii Masao||2014-12-26 06:24:44||Re: [REVIEW] Re: Compression of full-page-writes|
|Previous Message||Shigeru Hanada||2014-12-26 04:48:59||Re: Join push-down support for foreign tables|