On 31 January 2012 19:49, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> In the case when we're asked to clear a bit, it would first try to pin >> the relevant page, which would go through vm_readbuf() with extend set >> to true. Then vm_extend() would notice that the visibility map had >> already been extended, and it would read in the new page with the set >> bit. So this case would continue to work, wouldn't it? > > Ah, maybe. I haven't tried to code it up. Do you want to take a crack at it? >
Well the patch upthread works when it comes to reducing the cost of testing bits in the visibility map by not bothering to look for pages which appear to be past the end of the file. And when pinning pages for setting or clearing bits, it still checks for new pages created by other backends. The thing I'm unsure about is whether sending sinval messages when the visibility map is extended is a good idea. It could work without that, but then a backend would never notice that the visibility map had been created or extended by another process, so it's index-only scans would continue to perform like normal index scans. The sinval messages would cure that (eventually) but I'm not sure what other side-effects that might have. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
