Simon Riggs <si...@2ndquadrant.com> writes:
> On 12 September 2014 14:54, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
>> My idea is that we would have a new executor flag, say
>> EXEC_FLAG_READ_ONLY; we would set it on nodes that are known to be
>> read-only, and reset it on those that aren't, such as LockRows and
>> ModifyTable (obviously we need to pass it down correctly from parent to
>> children). Then in ExecInitSeqScan and ExecInitIndexScan, if we see the
>> flag set, we call heap/index_set_allow_prune(false) for the heap scan;
>> same thing in index scans. (I envisioned it as a boolean rather than
>> enabling a certain number of cleanups per scan.)
>>
>> I tried to code this but I think it doesn't work correctly, and no time
>> for debug currently. Anyway let me know what you think of this general
>> idea.
> Thanks for looking at this.
> My concern was to ensure that UPDATEs and DELETEs continue to call
> heap_page_prune_opt while larger SELECTs do not.
I think there's another way to think about it: what about saying that
the query's target relation(s) are subject to pruning, while others
are not? Then you do not need an executor flag, you just need to
look at the estate->es_result_relations array (or maybe even only at
estate->es_result_relation_info). This would have the advantage of
doing what-I-think-is-the-right-thing for updates/deletes involving
joins to other tables. The mechanism Alvaro describes would probably
have to prune all tables involved in such a query; do we really want
that?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
