Hello, > > BTW, why aren't you using the tlist passed to this function? I guess > >> create_scan_plan() passes tlist after processing it, so that should be > >> used rather than rel->reltargetlist. > >> > > > > I think that that would be maybe OK, but I think that it would not be > > efficient to use the list to compute attrs_used, because the tlist would > > have more information than rel->reltargetlist in cases where the tlist is > > build through build_physical_tlist(). > > > > > In that case, we can call build_relation_tlist() for foreign tables.
# is it build_base_rel_tilst() ? It needs only one effective line added, which would be seemingly far simple ingoring potential extra calculation for non-child relations (I suppose getting rid of it needs a foreach on rel->append_rel_list..) and too-longer physical tlist. On the other hand build_relation_tlist() and this patch seem to be in the same order of computational complexity for the length of the tlist. I prefer to use build_base_rel_tlist() for the clarity of code. But I don't know how high the chance to big physical tlist and non-child relations become to be an annoyance. Is there any suggestions? By the way, I tried xmin and xmax for the file_fdw tables. postgres=# select tableoid, xmin, xmax, * from passwd1; tableoid | xmin | xmax | uname | pass | uid | gid | .. 16396 | 244 | 4294967295 | root | x | 0 | 0 | root... 16396 | 252 | 4294967295 | bin | x | 1 | 1 | bin... 16396 | 284 | 4294967295 | daemon | x | 2 | 2 | daemon... The xmin and xmax apparently doesn't look sane. After some investigation, I found that they came from the following place in heap_form_tuple(), (call stach is show below) | HeapTupleHeaderSetDatumLength(td, len); | HeapTupleHeaderSetTypeId(td, tupleDescriptor->tdtypeid); | HeapTupleHeaderSetTypMod(td, tupleDescriptor->tdtypmod); HeapTupleHeader is a union of HeapTupleFields and DatumTupleFields and these macors seem to treat it as the latter. Then later this tuple seems to be read as the former so xmin and xmax should have that values. This seems to be a bug. But I have no idea how to deal with it for now. I'll take more look into this. The call stack onto the above heap_form_tuple is as follows. #0 heap_form_tuple (tupleDescriptor=0x7fc46d2953a8, values=0x10dd1a0, isnull=0x10dd1f8 "") at heaptuple.c:731 #1 ExecCopySlotTuple (slot=0x10dd0e0) at execTuples.c:574 #2 ExecMaterializeSlot (slot=0x10dd0e0) at execTuples.c:760 #3 ForeignNext (node=0x10dc7b0) at nodeForeignscan.c:61 #4 ExecScanFetch (node=0x10dc7b0, accessMtd=0x66599c <ForeignNext>, recheckMtd=0x665a43 <ForeignRecheck>) at execScan.c:82 #5 ExecScan (node=0x10dc7b0, accessMtd=0x66599c <ForeignNext>, recheckMtd=0x665a43 <ForeignRecheck>) at execScan.c:167 #6 ExecForeignScan (node=0x10dc7b0) at nodeForeignscan.c:91 #7 ExecProcNode (node=0x10dc7b0) at execProcnode.c:442 regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
