IP Library Granted Patent US 12,645,657
Granted Patent B2
US 12,645,657 · App. 18/143,768 · Granted Jun 2, 2026

Performing in-memory columnar analytic queries on externally resident data

Inventors: Roger Dermot MacNicol (Stevens, PA); Xia Hua (Mountain View, CA); Allison Holloway (San Carlos, CA); Shasank Kisan Chavan (Menlo Park, CA); Jesse Kamp (Castro Valley, CA); Maria Colgan (Menlo Park, CA); Tirthankar Lahiri (Palo Alto, CA)
Assignee: Oracle International Corporation
G06F16/221G06F16/219G06F16/2237G06F16/2455G06F16/2456G06F16/2471G06F16/248G06F16/256
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,645,657
App. No.
18/143,768
Granted
Jun 2, 2026
Kind
B2
Abstract

Techniques herein use in-memory column vectors to process data that is external to a database management system (DBMS) and logically join the external data with data that is native to the DBMS. In an embodiment, a computer maintains a data dictionary for native data that is durably stored in an DBMS and external data that is not durably stored in the DBMS. From a client through a connection to the DBMS, the computer receives a query. The computer loads the external data into an in-memory column vector that resides in random access memory of the DBMS. Based on the query and the data dictionary, the DBMS executes a data join of the in-memory column vector with the native data. To the client through said connection, the computer returns results of the query based on the data join.

Claims (43)

1 . A method comprising:

maintaining a data dictionary for:

native data that is persisted in a database management system (DBMS), and

external data that is not persisted in the DBMS;

loading, based on the data dictionary, the external data into a first in-memory column vector of a plurality of in-memory column vectors that reside in a random access memory of the DBMS, wherein said loading the external data comprises:

dictionary encoding the external data, and

generating a monotonically increasing sequence of distinct row numbers;

generating a second in-memory vector of said plurality of in-memory column vectors that contains the monotonically increasing sequence of distinct row numbers;

after said loading and dictionary encoding the external data, receiving a query; and

executing the query based on: the data dictionary, said monotonically increasing sequence of distinct row numbers, and the plurality of in-memory column vectors;

wherein the method is performed by one or more computers.

2 . The method of claim 1 , wherein results of the query include a particular distinct row number of said monotonically increasing sequence of distinct row numbers.

3 . The method of claim 1 further comprising using, for a relational operation, a particular distinct row number of said monotonically increasing sequence of distinct row numbers.

4 . The method of claim 3 wherein said using, for a relational operation, a particular distinct row number comprises using, for a relational join, said particular distinct row number.

5 . The method of claim 4 further comprising performing the relational join by using a dense key while scanning the first in-memory column vector that contains the external data.

6 . The method of claim 5 further comprising applying, based on said monotonically increasing sequence of distinct row numbers, a window function to the first in-memory column vector that contains the external data.

7 . The method of claim 6 further comprising generating the dense key based on a column in a relational table persisted in the DBMS.

8 . The method of claim 7 wherein said generating the dense key comprises obtaining the dense key based on an encoding dictionary of the column in the relational table.

9 . The method of claim 4 wherein the relational join comprises using an octet that contains multiple key values.

10 . The method of claim 1 further comprising:

persisting a database checkpoint that contains the plurality of in-memory column vectors;

copying the plurality of in-memory column vectors into the random access memory of the DBMS.

11 . One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause:

maintaining a data dictionary for:

native data that is persisted in a database management system (DBMS), and

external data that is not persisted in the DBMS;

loading, based on the data dictionary, the external data into a first in-memory column vector of a plurality of in-memory column vectors that reside in a random access memory of the DBMS, wherein said loading the external data comprises:

dictionary encoding the external data, and

generating a monotonically increasing sequence of distinct row numbers;

generating a second in-memory vector of said plurality of in-memory column vectors that contains the monotonically increasing sequence of distinct row numbers;

after said loading and dictionary encoding the external data, receiving a query; and

executing the query based on: the data dictionary, said monotonically increasing sequence of distinct row numbers, and the plurality of in-memory column vectors.

12 . The one or more non-transitory computer-readable media of claim 11 , wherein results of the query include a particular distinct row number of said monotonically increasing sequence of distinct row numbers.

13 . The one or more non-transitory computer-readable media of claim 11 wherein the instructions further cause using, for a relational operation, a particular distinct row number of said monotonically increasing sequence of distinct row numbers.

14 . The one or more non-transitory computer-readable media of claim 13 wherein said using, for a relational operation, a particular distinct row number comprises using, for a relational join, said particular distinct row number.

15 . The one or more non-transitory computer-readable media of claim 14 wherein the instructions further cause performing the relational join by using a dense key while scanning the first in-memory column vector that contains the external data.

16 . The one or more non-transitory computer-readable media of claim 15 wherein the instructions further cause applying, based on said monotonically increasing sequence of distinct row numbers, a window function to the first in-memory column vector that contains the external data.

17 . The one or more non-transitory computer-readable media of claim 16 wherein the instructions further cause generating the dense key based on a column in a relational table persisted in the DBMS.

18 . The one or more non-transitory computer-readable media of claim 17 wherein said generating the dense key comprises obtaining the dense key based on an encoding dictionary of the column in the relational table.

19 . The one or more non-transitory computer-readable media of claim 14 wherein the relational join comprises using an octet that contains multiple key values.

20 . The one or more non-transitory computer-readable media of claim 11 wherein the instructions further cause:

persisting a database checkpoint that contains the plurality of in-memory column vectors;

copying the plurality of in-memory column vectors into the random access memory of the DBMS.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded May 5, 2023
From: MACNICOL, ROGER DERMOT; HUA, XIA; HOLLOWAY, ALLISON; CHAVAN, SHASANK KISAN; KAMP, JESSE; COLGAN, MARIA; LAHIRI, TIRTHANKAR
To: ORACLE INTERNATIONAL CORPORATION
Reel/Frame 063554/0860 →
Continuity (3)
Continuation 16135748 · Sep 19, 2018
Provisional Application 62566386 · Sep 30, 2017
Related Publication 20230273910A1 · Aug 31, 2023
References Cited (14)
US 9916352B2 · Chaudhry et al. · 2018 [cited by applicant]
US 10599625B2 · Tran et al. · 2020 [cited by applicant]
US 20130151502A1 · Yoon · 2013 [cited by examiner]
US 20140317084A1 · Chaudhry et al. · 2014 [cited by applicant]
US 20150088809A1 · Kociubes · 2015 [cited by examiner]
US 20150213072A1 · Chen et al. · 2015 [cited by applicant]
US 20150356131A1 · McClary · 2015 [cited by examiner]
US 20160070726A1 · Macnicol · 2016 [cited by examiner]
US 20170017683A1 · Fourny et al. · 2017 [cited by applicant]
US 20170116242A1 · Chavan et al. · 2017 [cited by applicant]
US 20170147618A1 · Geissinger · 2017 [cited by examiner]
US 20170243028A1 · LaFever et al. · 2017 [cited by applicant]
US 20190095487A1 · Le et al. · 2019 [cited by applicant]
KD Nuggets, “Apache Arrow and Apache Parquet: Why We Needed Different Projects for Columnar Data, On Disk and In-Memory”, www.kdnuggets.com/2017/02/apache-arrow-parquet-columnar-data, Feb. 2017, 8pgs. [cited by applicant]