On Sun, Mar 24, 2013 at 11:14 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers