Re: EvalPlanQual behaves oddly for FDW queries involving system columns
От | Etsuro Fujita |
---|---|
Тема | Re: EvalPlanQual behaves oddly for FDW queries involving system columns |
Дата | |
Msg-id | 552B9356.5070904@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: EvalPlanQual behaves oddly for FDW queries involving system columns (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: EvalPlanQual behaves oddly for FDW queries involving
system columns
|
Список | pgsql-hackers |
On 2015/04/10 21:40, Etsuro Fujita wrote: > On 2015/04/09 12:07, Etsuro Fujita wrote: >> I'll update the patch, which will contain only an infrastructure for >> this in the PG core, and will not contain any postgres_fdw change. > > I updated the patch based on your comments. Updated patch attached. In > the patch the following FDW APIs have been proposed: > > + RowMarkType > + GetForeignRowMarkType (LockClauseStrength strength); > > + bool > + LockForeignRow (EState *estate, > + ExecRowMark *erm, > + ItemPointer tupleid); > > + HeapTuple > + FetchForeignRow (EState *estate, > + ExecRowMark *erm, > + ItemPointer tupleid); > > I think that these APIs allow the FDW that has TIDs to use the rowmark > options such as ROW_MARK_REFERENCE, ROW_MARK_SHARE and > ROW_MARK_EXCLUSIVE for its foreign tables so as to match the local > semantics exactly, for example. > > As you mentioned, it would be better to add helper functions to see > whether the foreign table is referenced by any ExecRowMarks. ISTM that > an easy way to do that is to modify ExecFindRowMark() so that it allows > for the missing case. I didn't contain such functions in the patch, though. I added that function and modified docs a bit. Please find attached an updated version of the patch. Best regards, Etsuro Fujita
Вложения
В списке pgsql-hackers по дате отправления: