>> I created a database to support an application that tracks events on different objects. The two main tables are tbl_Object [sic: violates ISO-11179 rules and is too vague] and tbl_EventLog [sic: violates ISO-11179 rules].

Pull off that silly "tbl-" prefix and start thinking in sets; in this
case, you should have plural names, unless there actually is only one
"object" and only one "event"

>> Each table has unique ID and on the tbl_EventLog there is FK for a record [sic: rows are not records] in the tbl_Object. <<

>> The events are inserted all the time for the same or different objects from the tbl_Object. There are about 600,000 objects in the tbl_Object [sic] and 1,500,000 (and growing) events in tbl_EventLog. <<

This is the wrong data model. The usual design error is to have only
one time in a row to capture when an event started, then do horrible
self-joins to get the duration
of the status change. Let me use a history table for price changes.
The fact to store is that a price had a duration:

CREATE TABLE PriceHistory
(upc CHAR(13) NOT NULL
REFERENCES Inventory(upc),
start_date DATE NOT NULL,
end_date DATE, -- null means current
CHECK(start_date < end_date),
PRIMARY KEY (upc, start_date),
item_price DECIMAL (12,4) NOT NULL
CHECK (item_price > 0.0000),
etc.);

You actually needs more checks to assure that the start date is at
00:00 and the end dates is at 23:59:59.999.. Hrs. You then use a
BETWEEN predicate to get the appropriate price.

SELECT ..
FROM PriceHistory AS H, Orders AS O
WHERE O.sales_date BETWEEN H.start_date
AND COALESCE (end_date, CURRENT_TIMESTAMP);

It is also a good idea to have a VIEW with the current data:

CREATE VIEW CurrentPrices (..)
AS
SELECT ..
FROM PriceHistory
WHERE end_date IS NULL;

Now, download the Rick Snodgrass book on Temporal Queries in SQL from
the University of Arizona website (it is free). And finally Google up
my article at www.DBAzine.com on transition constraints.