On Wed, Mar 15, 2017 at 9:28 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Mar 15, 2017 at 11:37 AM, Ashutosh Sharma <ashu.coe...@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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers