Re: the big picture for index-only scans

On Sat, Aug 20, 2011 at 2:51 AM, Gokulakannan Somasundaram <
gokul007(at)gmail(dot)com> wrote:

> On Sat, Aug 20, 2011 at 2:25 AM, Heikki Linnakangas <
> heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>> On 19.08.2011 21:06, Gokulakannan Somasundaram wrote:
>>
>>> If you are following the same design that Heikki put forward, then there
>>> is
>>> a problem with it in maintaining the bits in page and the bits in
>>> visibility
>>> map in sync, which we have already discussed.
>>>
>>
>> Are you referring to this: http://archives.postgresql.**
>> org/pgsql-hackers/2010-02/**msg02097.php<http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php>? I believe Robert's changes to make the visibility map crash-safe covers
>> that. Clearing the bit in the visibility map now happens within the same
>> critical section as clearing the flag on the heap page and writing th WAL
>> record.
>>
>> In that case, say a 100 sessions are trying to update records which fall
> under the 8000*4 heap pages( i assume 2 bits per visibility map - 8 * 1024 *
> 4 exact) covered by one page of visibility map, won't it make the 99
> sessions wait for that visibility map while holding the exclusive lock on
> the 99 heap pages?
> Are we going to say, that these kind of situations occur very rarely? Or
> that the loss of scalability in these situations, is worth the performance
> during the read-heavy workloads?
>
> In any case, making a database going through all these extra overheads,
> while they don't even have any index-only scans!!! That definitely should
> be given a thought.
>
> Gokul.
>

Please consider the update, i mentioned above occurs and changes the
visibility bit of the page.