Simon Riggs wrote: > 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. > > This is achieved without a counter, so after some thought like it > better; simple is good. Happy to progress from here, or you can?
Please feel free to take over. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers