aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeBitmapHeapscan.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2024-10-31 10:02:58 +0200
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2024-10-31 10:02:58 +0200
commit8e2e2662214a0a6d0fb23a070ea78d691d8ced43 (patch)
tree9873173c41f983dadc00e7f7e628fef233b58cce /src/backend/executor/nodeBitmapHeapscan.c
parent3974bc319639ad7da5934ba8d04d474a6f7fdee6 (diff)
downloadpostgresql-8e2e2662214a0a6d0fb23a070ea78d691d8ced43.tar.gz
postgresql-8e2e2662214a0a6d0fb23a070ea78d691d8ced43.zip
Simplify call to rebuild relcache entry for indexes
RelationClearRelation(rebuild == true) calls RelationReloadIndexInfo() for indexes. We can rely on that in RelationIdGetRelation(), instead of calling RelationReloadIndexInfo() directly. That simplifies the code a little. In the passing, add a comment in RelationBuildLocalRelation() explaining why it doesn't call RelationInitIndexAccessInfo(). It's because at index creation, it's called before the pg_index row has been created. That's also the reason that RelationClearRelation() still needs a special case to go through the full-blown rebuild if the index support information in the relcache entry hasn't been populated yet. Reviewed-by: jian he <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/9c9e8908-7b3e-4ce7-85a8-00c0e165a3d6%40iki.fi
Diffstat (limited to 'src/backend/executor/nodeBitmapHeapscan.c')
0 files changed, 0 insertions, 0 deletions