On Wed, Mar 15, 2017 at 9:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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().
Okay, I have done the changes as suggested by you. Please refer to the
attached v8 patch. Thanks.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
