Re: Index-only scan performance regression

On 31 January 2012 19:49, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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