Re: [HACKERS] OR clause - check code
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] OR clause - check code |
Дата | |
Msg-id | 199808011713.NAA25935@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] OR clause - check code (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
> Bruce Momjian wrote: > > > > Vadim, would you please review this code, and let me know if it is > > correct. I am unsure about the calls to ExecStoreTuple(), ExecQual() > > (is proper context used?), and placement of ReleaseBuffer(). Do I need > ^^^^^^^^^^^^^^^^^^^^^^ > Yes. > execScan.c:ExecScan() sets econtext->ecxt_scantuple = slot <-- > returned by Seq/Index scan -- before check Scan qual and > so econtext->ecxt_scantuple already points to the slot where > you store new tuple. It seems that no one change this pointer... > > But did you try to use multi-index scan in inner plan of > Nestloop? It seems that you should add this to ExecIndexReScan(): No. I just don't understand the behavior of the various join types on index use. > > if (exprCtxt != NULL) > node->scan.scanstate->cstate.cs_ExprContext->ecxt_outertuple = > exprCtxt->ecxt_outertuple; Added. > > Also, ExecIndexReScan() evaluates run-time keys for _current_ > index scan only - this must be changed and indexstate->iss_IndexPtr > must be setted to 0. I have added this to the code. > > to free the tuple buffer if I decide it doesn't meet my ExecQual test? > > Yes, you have to free buffer. Done. Vadim, I am going to send you the current nodeIndexscan.c for your review, to make sure I made the proper changes. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: