On Wed, Mar 15, 2017 at 11:37 AM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>> + /* Get RelfileNode from relation OID */
>> + rel = relation_open(htup->t_tableOid, NoLock);
>> + rnode = rel->rd_node;
>> + relation_close(rel, NoLock);
>> itup->t_tid = htup->t_self;
>> - _hash_doinsert(index, itup);
>> + _hash_doinsert(index, itup, rnode);
>>
>> This is an awfully low-level place to be doing something like this.
>> I'm not sure exactly where this should be happening, but not in the
>> per-tuple callback.
>
> Okay, Now I have done this inside _hash_doinsert() instead of callback
> function. Please have a look into the attached v7 patch.
In the btree case, the heap relation isn't re-opened from anywhere in
the btree code. I think we should try to do the same thing here. If
we add an argument for the heap relation to _hash_doinsert(),
hashinsert() can easily it down; it's already got that value
available. There are two other calls to _hash_doinsert:
1. _h_indexbuild() calls _hash_doinsert(). It's called only from
hashbuild(), which has the heap relation available. So we can just
add that as an extra argument to _h_indexbuild() and then from there
pass it to _hash_doinsert.
2. hashbuildCallback calls _hash_doinsert(). It's sixth argument is a
HashBuildState which is set up by hashbuild(), which has the heap
relation available. So we can just add an extra member to the
HashBuildState and have hashbuild() set it before calling
IndexBuildHeapScan. hashbuildCallback can then fish it out of the
HashBuildState and pass it to _hash_doinsert().
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
