On Mon, Feb 12, 2024 at 7:47 PM Peter Eisentraut <pe...@eisentraut.org> wrote: > > > In principle, hashRowType() could process all the fields that > equalRowTypes() does. But since it's only a hash function, it doesn't > have to be perfect. (This is also the case for the current > hashTupleDesc().) I'm not sure where the best tradeoff is.
That's where my confusion comes from. hashRowType is used in record_type_typmod_hash. record_type_typmod_hash is within assign_record_type_typmod. in assign_record_type_typmod: ------------------------------------------------ if (RecordCacheHash == NULL) { /* First time through: initialize the hash table */ HASHCTL ctl; ctl.keysize = sizeof(TupleDesc); /* just the pointer */ ctl.entrysize = sizeof(RecordCacheEntry); ctl.hash = record_type_typmod_hash; ctl.match = record_type_typmod_compare; RecordCacheHash = hash_create("Record information cache", 64, &ctl, HASH_ELEM | HASH_FUNCTION | HASH_COMPARE); /* Also make sure CacheMemoryContext exists */ if (!CacheMemoryContext) CreateCacheMemoryContext(); } /* * Find a hashtable entry for this tuple descriptor. We don't use * HASH_ENTER yet, because if it's missing, we need to make sure that all * the allocations succeed before we create the new entry. */ recentry = (RecordCacheEntry *) hash_search(RecordCacheHash, &tupDesc, HASH_FIND, &found); ------------------------------------------------ based on the comments in hash_create. The above hash_search function would first use record_type_typmod_hash to find out candidate entries in a hash table then use record_type_typmod_compare to compare the given tupDesc with candidate entries. Is this how the hash_search in assign_record_type_typmod works? equalRowTypes processed more fields than hashRowType, hashRowType comments mentioned equalRowTypes, maybe we should have some comments in hashRowType explaining why only hashing natts, tdtypeid, atttypid will be fine.