On 24 March 2013 13:29, Greg Stark <st...@mit.edu> wrote: > 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'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? Yep, that's what I'm proposing. > 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. ...and as a result, the rest of your comments don't apply at all to the proposal. Sorry about that confusion. -- Simon Riggs 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
