Be more tense about not creating tuplestores with randomAccess = true unless
Tom Lane <tgl@sss.pgh.pa.us>
Be more tense about not creating tuplestores with randomAccess = true unless backwards scan could actually happen. In particular, pass a flag to materialize-mode SRFs that tells them whether they need to require random access. In passing, also suppress unneeded backward-scan overhead for a Portal's holdStore tuplestore. Per my proposal about reducing I/O costs for tuplestores.
Files
| Path | Change | +/− |
|---|---|---|
| contrib/tablefunc/tablefunc.c | modified | +14 −7 |
| contrib/xml2/xpath.c | modified | +4 −2 |
| src/backend/commands/prepare.c | modified | +4 −2 |
| src/backend/executor/execQual.c | modified | +8 −4 |
| src/backend/executor/nodeFunctionscan.c | modified | +4 −2 |
| src/backend/utils/fmgr/README | modified | +5 −1 |
| src/backend/utils/mmgr/portalmem.c | modified | +13 −5 |
| src/include/executor/executor.h | modified | +3 −2 |
| src/include/nodes/execnodes.h | modified | +5 −2 |
| src/pl/plperl/plperl.c | modified | +3 −2 |
| src/pl/plpgsql/src/pl_exec.c | modified | +4 −2 |