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(). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers