Re: [HACKERS] Add pgstathashindex() to get hash index table statistics. - Mailing list pgsql-hackers

From Kuntal Ghosh
Subject Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.
Date
Msg-id CAGz5QCJpySmvSfa3_b26rb_Q_dQ4dyrSCXZgaskY3ruLznYJpg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Jan 24, 2017 at 10:09 AM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>> I've looked at the patch. It looks good. However, I was wondering why
>> an exclusive lock for extension is necessary for reading the number
>> blocks in this case. Please refer to the following code.
>>
>> +       /* Get the current relation length */
>> +       LockRelationForExtension(rel, ExclusiveLock);
>> +       nblocks = RelationGetNumberOfBlocks(rel);
>> +       UnlockRelationForExtension(rel, ExclusiveLock);
>>
>> Apart from this, I've nothing else to add.
>
>
> Actually in my case I may not need to acquire ExclusiveLock just to
> get the number of pages in a relation. Infact I have already opened a
> relation using
> 'AccessShareLock' which should be enough to read a table length.
> Thanks for putting this point. I have corrected it in the attached v5
> patch.
I've checked the last attached patch and didn't find any issue. There
is no problem with patching and compilation. It also passed all
regression tests.
Nothing else to add from my side. I'm marking this 'Ready for commiter'.

-- 
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andrew Borodin
Date:
Subject: Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree
Next
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] Failure in commit_ts tap tests