You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudberry.apache.org by re...@apache.org on 2024/12/24 07:25:56 UTC
(cloudberry) branch reshke-patch-1 created (now 82e21771ba)
This is an automated email from the ASF dual-hosted git repository.
reshke pushed a change to branch reshke-patch-1
in repository https://gitbox.apache.org/repos/asf/cloudberry.git
at 82e21771ba Update appendonlyblockdirectory.c: imporve coding style.
This branch includes the following new commits:
new 82e21771ba Update appendonlyblockdirectory.c: imporve coding style.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: commits-help@cloudberry.apache.org
(cloudberry) 01/01: Update appendonlyblockdirectory.c: imporve coding style.
Posted by re...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
reshke pushed a commit to branch reshke-patch-1
in repository https://gitbox.apache.org/repos/asf/cloudberry.git
commit 82e21771ba64bb89ae4ab71775d808070983fffa
Author: reshke <re...@double.cloud>
AuthorDate: Tue Dec 24 12:25:51 2024 +0500
Update appendonlyblockdirectory.c: imporve coding style.
Completely remove code pattern unnatural for PostgreSQL kernel code style.
---
.../access/appendonly/appendonlyblockdirectory.c | 68 ++++++++++------------
1 file changed, 32 insertions(+), 36 deletions(-)
diff --git a/src/backend/access/appendonly/appendonlyblockdirectory.c b/src/backend/access/appendonly/appendonlyblockdirectory.c
index b0d4876086..a5bac67e24 100644
--- a/src/backend/access/appendonly/appendonlyblockdirectory.c
+++ b/src/backend/access/appendonly/appendonlyblockdirectory.c
@@ -549,6 +549,7 @@ AppendOnlyBlockDirectory_GetEntry(
&blockDirectory->minipages[columnGroupNo];
int entry_no = -1;
int tmpGroupNo;
+ MinipagePerColumnGroup *minipageInfo;
if (blkdirRel == NULL || blkdirIdx == NULL)
{
@@ -692,48 +693,43 @@ AppendOnlyBlockDirectory_GetEntry(
systable_endscan_ordered(idxScanDesc);
}
+
- {
- MinipagePerColumnGroup *minipageInfo;
+ minipageInfo = &blockDirectory->minipages[columnGroupNo];
- minipageInfo = &blockDirectory->minipages[columnGroupNo];
+ /*
+ * Perform a binary search over the minipage to find the entry about
+ * the AO block.
+ */
+ entry_no = find_minipage_entry(minipageInfo->minipage,
+ minipageInfo->numMinipageEntries,
+ rowNum);
+ /* If there are no entries, return false. */
+ if (entry_no == -1 && minipageInfo->numMinipageEntries == 0)
+ return false;
+
+ if (entry_no == -1)
+ {
/*
- * Perform a binary search over the minipage to find the entry about
- * the AO block.
+ * Since the last few blocks may not be logged in the block
+ * directory, we always use the last entry.
+ *
+ * FIXME: If we didn't find a suitable entry, why even use the last
+ * entry? Currently, as it stands we would most likely return
+ * true from this function. This will lead to us having to do a
+ * fetch of the tuple from the physical file in the layer above (see
+ * scanToFetchTuple()), where we would ultimately find the tuple
+ * missing. Would it be correct to set the directory entry here to
+ * be the last one (for caching purposes) and return false, in order
+ * to avoid this physical file read?
*/
- entry_no = find_minipage_entry(minipageInfo->minipage,
- minipageInfo->numMinipageEntries,
- rowNum);
-
- /* If there are no entries, return false. */
- if (entry_no == -1 && minipageInfo->numMinipageEntries == 0)
- return false;
-
- if (entry_no == -1)
- {
- /*
- * Since the last few blocks may not be logged in the block
- * directory, we always use the last entry.
- *
- * FIXME: If we didn't find a suitable entry, why even use the last
- * entry? Currently, as it stands we would most likely return
- * true from this function. This will lead to us having to do a
- * fetch of the tuple from the physical file in the layer above (see
- * scanToFetchTuple()), where we would ultimately find the tuple
- * missing. Would it be correct to set the directory entry here to
- * be the last one (for caching purposes) and return false, in order
- * to avoid this physical file read?
- */
- entry_no = minipageInfo->numMinipageEntries - 1;
- }
- return set_directoryentry_range(blockDirectory,
- columnGroupNo,
- entry_no,
- directoryEntry);
+ entry_no = minipageInfo->numMinipageEntries - 1;
}
-
- return false;
+ return set_directoryentry_range(blockDirectory,
+ columnGroupNo,
+ entry_no,
+ directoryEntry);
}
/*
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: commits-help@cloudberry.apache.org