Redundant assignment of table OID for a HeapTuple?
Hi hackers. I found a strange point when I was reading the heapam
handlers of table access method, where heapam_tuple_insert and several
handlers explicitly assign t_tableOid of the tuple to be operated,
while later the t_tableOid is assigned again by like heap_prepare_insert or
so. Is it redundant? Better to do it together with other tuple
initialization
code?
Regards,
Jingtang
Attachments:
0001-Remove-redundant-assignment-of-HeapTuple-table-oid.patchapplication/octet-stream; name=0001-Remove-redundant-assignment-of-HeapTuple-table-oid.patchDownload
From 8e41c1d74f1a9aa379bdfdafff55866c3584a5b9 Mon Sep 17 00:00:00 2001
From: Jingtang Zhang <mrdrivingduck@gmail.com>
Date: Fri, 23 Aug 2024 19:35:04 +0800
Subject: [PATCH] Remove redundant assignment of HeapTuple table oid
The t_tableOid of HeapTuple has been assigned in the heapam handler of
table access method for the first time, and later in
heap_prepare_insert for the second time.
---
src/backend/access/heap/heapam.c | 1 -
src/backend/access/heap/heapam_handler.c | 3 ---
2 files changed, 4 deletions(-)
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 91b20147a0..07e7d59a30 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -2293,7 +2293,6 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
tuple = ExecFetchSlotHeapTuple(slots[i], true, NULL);
slots[i]->tts_tableOid = RelationGetRelid(relation);
- tuple->t_tableOid = slots[i]->tts_tableOid;
heaptuples[i] = heap_prepare_insert(relation, tuple, xid, cid,
options);
}
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 1c6da286d4..1aaea99dca 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -245,7 +245,6 @@ heapam_tuple_insert(Relation relation, TupleTableSlot *slot, CommandId cid,
/* Update the tuple with table oid */
slot->tts_tableOid = RelationGetRelid(relation);
- tuple->t_tableOid = slot->tts_tableOid;
/* Perform the insertion, and copy the resulting ItemPointer */
heap_insert(relation, tuple, cid, options, bistate);
@@ -265,7 +264,6 @@ heapam_tuple_insert_speculative(Relation relation, TupleTableSlot *slot,
/* Update the tuple with table oid */
slot->tts_tableOid = RelationGetRelid(relation);
- tuple->t_tableOid = slot->tts_tableOid;
HeapTupleHeaderSetSpeculativeToken(tuple->t_data, specToken);
options |= HEAP_INSERT_SPECULATIVE;
@@ -321,7 +319,6 @@ heapam_tuple_update(Relation relation, ItemPointer otid, TupleTableSlot *slot,
/* Update the tuple with table oid */
slot->tts_tableOid = RelationGetRelid(relation);
- tuple->t_tableOid = slot->tts_tableOid;
result = heap_update(relation, otid, tuple, cid, crosscheck, wait,
tmfd, lockmode, update_indexes);
--
2.39.3 (Apple Git-146)
On 23/08/2024 14:50, Jingtang Zhang wrote:
Hi hackers. I found a strange point when I was reading the heapam
handlers of table access method, where heapam_tuple_insert and several
handlers explicitly assign t_tableOid of the tuple to be operated,
while later the t_tableOid is assigned again by like heap_prepare_insert or
so. Is it redundant? Better to do it together with other tuple
initialization
code?
I wonder if we could get rid of t_tableOid altogether. It's only used in
a few places, maybe those places could get the informatiotion from
somewhere else. Notably, there's also a t_tableOid field in TupleTableSlot.
--
Heikki Linnakangas
Neon (https://neon.tech)