On Sun, Mar 24, 2013 at 11:14 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Proposal is to prevent SELECTs from causing more than N buffers from
> being dirtied by hint bit setting and block cleanup.
I think you need to clarify what you mean by this.
I'm guessing you mean that there would be a global variable somewhere
(why not a field in the executor node for the sequential scan?)
counting how many blocks were marked dirty by the current plan (why
not the whole transaction?) and once it reaches the limit subsequent
blocks would be processed normally including setting hint bits but
wouldn't mark the block dirty? (Or do you mean the hint bits wouldn't
even be set so even if the block was dirty they wouldn't be updated?)
This means that there's no limit to the number of times an in-doubt
record would have to have its xmin/xmax looked up in the clog. Every
select would have to do the same work over and over again
indefinitely.
The whole point of the hint bits is to guarantee that each update
causes a bounded amount of work. Each update transaction currently
causes one write, followed by a limited period when the transaction
status needs to be checked, followed by another write with the hint
bit set. And that's the total work caused. After that the record can
be read without consulting the clog or anything else.
--
greg