Gokulakannan Somasundaram wrote:
> Hmmm.... So whenever the update transaction changes a page, it will update
> the visibility map, but won't enter the WAL record.
> So after the crash we have a visibility map, which has false positives.
The WAL record of the heap insert/update/delete contains a flag
indicating that the visibility map needs to be updated too. Thus no need
for a separate WAL record.
>> Let me repeat myself: if you think the overhead of a visibility map is
>> noticeable or meaningful in any scenario, the onus is on you to show
>> what that scenario is. I am not aware of such a scenario, which doesn't
>> mean that it doesn't exist, of course, but hand-waving is not helpful.
>
> Well as a DB Tuner, i am requesting to make it a optional feature.
There is no point in making something optional, if there is no scenarios
where you would want to turn it off.
>> I'm not sure what you mean with "without any page level locking".
>> Whenever a visibility map page is read or modified, a lock is taken on
>> the buffer.
>>
> OK. I thought you are following some kind of lock-less algorithm there.
> Then updaters/deleters of multiple pages might be waiting on the same lock
> and hence there is a chance of a contention there right?
Yeah, there is some potential for contention. But again it doesn't seem
to be a problem in any real-life scenario; I didn't see any in the test
I performed, and IIRC I did try to invoke that case, and there has been
no reports of contention from users.
If it ever becomes a problem, maybe you could indeed switch to a
lock-less algorithm, but there doesn't seem to be any need for that.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
