to_microseconds

Applies to VAST Cluster 5.5.

Functions › Date and time functions › Interval constructors. Returns an interval of n microseconds (millionths of a second), the same as INTERVAL n MICROSECOND. Add it to a timestamp, or subtract it, to move by that many microseconds.

Syntax

to_microseconds(n)

Returns: INTERVAL.

Same as: INTERVAL n MICROSECOND for a constant n.

Set up the examples

The examples connect with the ADBC driver, as in VAST Query Engine (ADBC), and work in a schema called docs_sql_fn_date_time_to_microseconds. Set QE_ENDPOINT, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and VASTDB_BUCKET (SQL reference), and run the blocks in order in one Python session. Below each block is the output you should see.

This block connects, defines the run() and plan() helpers, and creates a table of four readings. Each has a time ts and an offset us in microseconds (a BIGINT). Row 4 has no values:

import os
import re

import adbc_driver_manager
import adbc_driver_manager.dbapi as dbapi
import adbc_driver_vastdb

BUCKET = os.environ["VASTDB_BUCKET"]
SCHEMA = f'"{BUCKET}/docs_sql_fn_date_time_to_microseconds"'

conn = dbapi.connect(
    driver=adbc_driver_vastdb.get_driver_path(),
    db_kwargs={
        "vast.db.endpoint": os.environ["QE_ENDPOINT"],
        "vast.db.access_key": os.environ["AWS_ACCESS_KEY_ID"],
        "vast.db.secret_key": os.environ["AWS_SECRET_ACCESS_KEY"],
    },
    autocommit=True,
)

def server_message(e):
    """The server's message in a driver error, without the request ID or the echoed statement."""
    text = re.sub(r"\[req=0x[0-9a-f]+\]: ", "", str(e))
    found = (re.search(r'message: "(.*?)", request_id', text, re.S)
             or re.search(r"description: (.*)\)", text, re.S))
    message = found.group(1) if found else text.strip().splitlines()[-1]
    message = re.sub(r"^Plan query: '.*?' failed with: ", "", message, flags=re.S)
    message = re.split(r"\\n|\n", message)[0].replace('\\"', '"')
    return message.replace(BUCKET, "<bucket>")

def run(sql):
    """Run one statement. Print the rows it returns, or the error."""
    try:
        with conn.cursor() as cur:
            cur.execute(sql)
            rows = cur.fetchall() if cur.description else []
    except (adbc_driver_manager.Error, OSError) as e:
        print(f"{type(e).__name__}: {server_message(e)}")
    else:
        print(rows)

def plan(sql):
    """Print the plan without its ~N Rows lines: the table's row count, which can still be 0 just after an insert."""
    with conn.cursor() as cur:
        cur.execute("EXPLAIN " + sql)
        steps = cur.fetchall()[0][1]
    print("\n".join(line for line in steps.splitlines() if "Rows" not in line))

TABLE = f"{SCHEMA}.readings"
run(f"CREATE SCHEMA IF NOT EXISTS {SCHEMA}")
run(f"CREATE TABLE IF NOT EXISTS {TABLE} (id BIGINT, ts TIMESTAMP, us BIGINT)")
run(f"INSERT INTO {TABLE} VALUES "
    "(1, TIMESTAMP '2024-02-29 00:00:00', 1), "
    "(2, TIMESTAMP '2026-03-01 08:30:45.123456', 1500000), "
    "(3, TIMESTAMP '2026-03-01 08:30:45', -250), "
    "(4, NULL, NULL)")

[]
[]
[(4,)]

What it does

to_microseconds(n) returns an interval with no months or days and a time part of n microseconds. The ADBC driver shows an interval as a MonthDayNano value, in nanoseconds: to_microseconds(2) is MonthDayNano(months=0, days=0, nanoseconds=2000).

A microsecond is the smallest step of a TIMESTAMP: TIMESTAMP '2024-02-29 00:00:00' + to_microseconds(1) is 2024-02-29 00:00:00.000001. A DATE plus the interval is a TIMESTAMP: DATE '2026-01-31' + to_microseconds(1) is 2026-01-31 00:00:00.000001.

The time part isn't turned into days: to_microseconds(1000000) is one second, and normalized_interval(to_microseconds(100)) is still 100 microseconds.

NULLs and edge cases

The same cases, as the cluster returns them. They use the table and helpers from Set up the examples:

run(f"SELECT id, to_microseconds(us) FROM {TABLE} WHERE id = 4")
run("SELECT to_microseconds(NULL), to_microseconds(0), to_microseconds(-1), to_microseconds('2'), "
    "to_microseconds(CAST(2 AS SMALLINT))")
run("SELECT to_microseconds(9223372036854775807)")
run("SELECT to_microseconds(9223372036854775808)")
run("SELECT to_microseconds(1.5)")
run("SELECT to_microseconds(DATE '2026-01-01')")

[(4, None)]
[(None, MonthDayNano(months=0, days=0, nanoseconds=0), MonthDayNano(months=0, days=0, nanoseconds=-1000), MonthDayNano(months=0, days=0, nanoseconds=2000), MonthDayNano(months=0, days=0, nanoseconds=2000))]
[(MonthDayNano(months=0, days=0, nanoseconds=-1000),)]
InternalError: Binder Error: No function matches the given name and argument types 'to_microseconds(INTEGER_LITERAL)'. You might need to add explicit type casts.
InternalError: Binder Error: No function matches the given name and argument types 'to_microseconds(DECIMAL(2,1))'. You might need to add explicit type casts.
InternalError: Binder Error: No function matches the given name and argument types 'to_microseconds(DATE)'. You might need to add explicit type casts.

Examples

The interval for each reading's offset, and the time moved by it:

run(f"SELECT id, us, to_microseconds(us), ts + to_microseconds(us) FROM {TABLE} ORDER BY id LIMIT 10")

[(1, 1, MonthDayNano(months=0, days=0, nanoseconds=1000), datetime.datetime(2024, 2, 29, 0, 0, 0, 1)), (2, 1500000, MonthDayNano(months=0, days=0, nanoseconds=1500000000), datetime.datetime(2026, 3, 1, 8, 30, 46, 623456)), (3, -250, MonthDayNano(months=0, days=0, nanoseconds=-250000), datetime.datetime(2026, 3, 1, 8, 30, 44, 999750)), (4, None, None, None)]

One microsecond after a timestamp and after a date, and one microsecond before a timestamp:

run("SELECT TIMESTAMP '2024-02-29 00:00:00' + to_microseconds(1), DATE '2026-01-31' + to_microseconds(1), "
    "TIMESTAMP '2024-02-29 00:00:00' - to_microseconds(1)")

[(datetime.datetime(2024, 2, 29, 0, 0, 0, 1), datetime.datetime(2026, 1, 31, 0, 0, 0, 1), datetime.datetime(2024, 2, 28, 23, 59, 59, 999999))]

How it runs in VAST

The Query Engine runs on the cluster's CNodes, and a query on a table starts with a scan in VAST DataBase (VAST_SCAN). VAST DataBase can evaluate a comparison of a column with a constant, but not a function of a column, so an interval built from a column is always computed by the Query Engine:

• In the SELECT list, the scan reads the column and the Query Engine computes to_microseconds() for each row it returns.
• In WHERE, the scan sends the columns for every row, and a FILTER step in the Query Engine computes the condition and keeps the rows that match. No rows are skipped in storage.

The plan of a condition on ts + to_microseconds(us) shows the FILTER step above the scan:

plan(f"SELECT id FROM {TABLE} WHERE ts + to_microseconds(us) > TIMESTAMP '2026-03-01 08:30:45'")

┌───────────────────────────┐
│         PROJECTION        │
│    ────────────────────   │
│             #2            │
│                           │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│           FILTER          │
│    ────────────────────   │
│ ((ts + to_microseconds(us)│
│ ) > '2026-03-01 08:30:45':│
│        :TIMESTAMP)        │
│                           │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│         VAST_SCAN         │
│    ────────────────────   │
│    Function: VAST_SCAN    │
│                           │
│        Projections:       │
│             ts            │
│             us            │
│             id            │
│                           │
└───────────────────────────┘

Make it faster

• Put the interval on the constant side. ts > TIMESTAMP '2026-03-01 08:30:45' + to_microseconds(1) compares the raw column with a value the Query Engine computes once, so the comparison is pushed down to VAST DataBase and rows that don't match never leave storage. The plan has no FILTER step:

plan(f"SELECT id FROM {TABLE} WHERE ts > TIMESTAMP '2026-03-01 08:30:45' + to_microseconds(1)")

┌───────────────────────────┐
│         VAST_SCAN         │
│    ────────────────────   │
│    Function: VAST_SCAN    │
│      Projections: id      │
│                           │
└───────────────────────────┘

• Store the result if you filter on it often. When the offset comes from a column, as us does here, there's no single constant to compare with. Compute ts + to_microseconds(us) when you write the rows and keep it in its own TIMESTAMP column; a comparison of that column with a constant is pushed down.

Limitations and errors

• Whole numbers only. A fraction fails with No function matches the given name and argument types 'to_microseconds(DECIMAL(2,1))'. For fractions of a larger unit, use to_milliseconds or to_seconds, which take a DOUBLE.
• Very large values come back wrong. At the top of the BIGINT range the result isn't checked: to_microseconds(9223372036854775807) returns nanoseconds=-1000, a negative interval, without an error. Express long spans in days, months or years.
• No time-zone support. Adding an interval to a TIMESTAMP WITH TIME ZONE, such as now(), fails. Cast the value to TIMESTAMP first; see time zones.

Similar functions

run("SELECT to_microseconds(1) = INTERVAL 1 MICROSECOND, to_milliseconds(1) = to_microseconds(1000), "
    "to_seconds(1) = to_microseconds(1000000)")
run("SELECT epoch_us(to_microseconds(1)), epoch(to_microseconds(1)), normalized_interval(to_microseconds(100))")

[(True, True, True)]
[(1, 1e-06, MonthDayNano(months=0, days=0, nanoseconds=100000))]

Clean up:

run(f"DROP TABLE IF EXISTS {TABLE}")
run(f"DROP SCHEMA IF EXISTS {SCHEMA}")
conn.close()

[]
[]

See also

• Date and time functions: all the date and time functions, and the interval constructors.
• plus: adding an interval to a date or timestamp.
• Where filters run and pushdowns.
• EXPLAIN: how to read a plan.