Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPnUL-0012GA-2V for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2026 20:25:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPnUJ-008NwK-1S for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2026 20:25:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPnUJ-008NwC-0Q for pgsql-hackers@lists.postgresql.org; Wed, 20 May 2026 20:25:56 +0000 Received: from mail-qk1-x734.google.com ([2607:f8b0:4864:20::734]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wPnUH-00000000bX6-3Irq for pgsql-hackers@lists.postgresql.org; Wed, 20 May 2026 20:25:55 +0000 Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-912475287a5so576187485a.2 for ; Wed, 20 May 2026 13:25:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779308750; cv=none; d=google.com; s=arc-20240605; b=befW6jAMhqkm1NUta6nvqYmzMZhOawuhbBSZKQUkDWNC/kEmwfFwEufCoUJ9cHiHZi AB4agn6ctYmFYR3+K02jLDlMyW+MsJqkbtR0u6I8L2m8qzTw6MHyGNw7KoukXgisaQwb 7he2cYQhXnfs/d/0dI9UtWWbHv6LvlxIUOiZEFdD+lVGMFwQ9HgwbOKDKhJXrrdZxSjY PEM2L/WOijn1PcYYJPv85jmnqAt6Oafeyqfmwf8h5w0k4clZVpvEvHIbZU7Kp8tRj/mZ ugf+bziYPPtx+ZNO4TNWmWR9Q9UE7PhIM1wbRkdSFxno+n/fgrUevs+zrIAuZG3LoYqZ LhhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=6SvMHZnYec/G+k2MiHjTRQRlsfTpR8gNFfJcT5axYXQ=; fh=dxJXJbLzq9Nah1LUdsj4QTuQ3JoDScd0wp1YHY64NXM=; b=SCm1D/mJaorfnZdnPwpE5i3/2+2w9eXymBVADuLnH2H55mR+sriS4o9xEaHzBUTOBM fi81ZsAxiLeW/EoANp+/BZIWpfaoOZzvymxCiopOJFzOEWM/+6VDU9nDn7CP6bZ6290O 3xkIdP8sTlWnvrJz30akVHTR9Li+Lfn495t813xeOJCLFspIlA2+1z4SFYOVSirVhUrK pH7HBl4RFcobPhXo0WMfcnM60KAgnX0JQ8UPxcrAswYMhY4+iXqFK7dwpihjteZzlaiy aB8NAZgYAjlc4rm1IdCi2trU1nNIq5c/UrIlNzD1NNam98DMlTcUXLkLapOtDADz3qh2 nv8Q==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779308750; x=1779913550; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=6SvMHZnYec/G+k2MiHjTRQRlsfTpR8gNFfJcT5axYXQ=; b=ahPz396rkBoTLst/3rHuOl2ImXnwIOKTfQ47f07zs02RcPbkr2kBKnNJgtVLYayupp K7svfDfcctHchlIZYwlDT6I6aYLCnu5xF2JWcANTsj4ob6eHH5IxRVfuMUxb60/VzDXK u371DzUxpAlH1SbGDwcNJudvnUdH2/rIIPMC5bBCq9gLgaiGDqyXG2pB6bE3NgyubD94 qeRVfIjqgV/JsQujd+k+wFHIE5RMFpdDnnYqj+QcNCGzKBOBbq14ozNnsW8JJmZxJ1p0 9MuIflnvTSYPubcANY8evylpsBP3uipNC4tnHbB78+HtU6YFH5HnvqbZETb+UHXOyzJz lyHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779308750; x=1779913550; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6SvMHZnYec/G+k2MiHjTRQRlsfTpR8gNFfJcT5axYXQ=; b=GmuIXGbYNrjVKgYAe5ECroTF6esVufSDS8zEDv+r+0eOwfCY/6ftYJImcD8Dr8QfJW ma/rmrBXvNF885cm4HeOMVFkPfleIu4yk8lOw6xRXGLIe/6QPfFSfEJxtZ+avjR0Yiow f4Mb8Ho3u59Yv8EawsvwtLq0uTfHbsMEON4/yEsH1t4Hi3EMQzkKbZpZ4E5kAK9ZGCC3 +exgmuecI339l1ogwFnDiPEkwg07K269Vw4C9l/3CKmyE2pK2ZpyCucE7ipnJJRr4Qao y1ICh00Su4YU5luw+7LvsFfoNufi6JpPlE9TkEn4SoivjyPGiOjIOU9l6YnDCNeFTBS7 C3Tw== X-Gm-Message-State: AOJu0Ywg8csyTuSn4bslhi5qbciuF+u+ykeJxPiKmFhiw15BHmomKq6a 3IzGcXRmtvn+BvLHZhuddLQBaPZHbwivUy69y5VGZe9RxgsA3CFqt9c770SG2CCL5x+qOGmpteW cok3pjcY0IyP4T+jjBxFrvhvGGe7XyVnOfHkm X-Gm-Gg: Acq92OFr2BlSxKEa2i0y+S40aE5HiXKPQNAf/+VzstcMh1PDho1b4bax0QzB7pmC49g YeQqFTExhZHDOkcG15KJYk3nM3NbZnyPzXF9o7MFDIYUYi8wXvkyhv4p4+BXmJsZDJUUD69NX2e BBy3NcBC2F1Lo+AueAfQiNuJGvTmHYO0n9vBd/CWJvTKPXy75eMaD1E1ElzemkVIm3lyNHxf9OB jh+XwfuWdea3Aadsq5TdhVeVHeogNSBDBFmB3qkvicljNnVwrFrqELrTnRbvYFWEw8PUmYK+wMZ v3u6eo0= X-Received: by 2002:a05:620a:8d88:b0:912:3ba0:d2d0 with SMTP id af79cd13be357-9123ba101afmr2433125485a.57.1779308750355; Wed, 20 May 2026 13:25:50 -0700 (PDT) MIME-Version: 1.0 From: Alex Malek Date: Wed, 20 May 2026 16:25:38 -0400 X-Gm-Features: AVHnY4KZADwf1_Wyd4O_JZNzXd3QHtN4bOm8Vu3js7bA8z5mIdbDUQYdmFtWxkE Message-ID: Subject: Feature request: Native nanosecond precision support for temporal types To: PostgreSQL Hackers Content-Type: multipart/alternative; boundary="00000000000002c1c50652459a5a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000002c1c50652459a5a Content-Type: text/plain; charset="UTF-8" Hello Hackers, Postgres temporal types (timestamp, timestamptz, and time) currently lag behind much of the analytical ecosystem in lacking native nanosecond precision support. Modern analytical and financial ecosystems increasingly require the ability to store and process nanosecond-resolution timestamps regardless of the precision of the local machine clock. Nanosecond timestamps are already common across: * Parquet (TIMESTAMP(NANOS)) * DuckDB (TIMESTAMP_NS) * ClickHouse (DateTime64(9)) * Oracle TIMESTAMP precision up to 9 fractional digits * SAS datetime values with nanosecond precision * Pandas / NumPy (datetime64[ns]) In practice, the lack of native PostgreSQL support forces applications into workarounds such as: * separate "nanosecond remainder" columns * bigint epoch-nanosecond encodings * custom/community temporal extensions e.g. https://github.com/optiver/timestamp9 Additionally native support would be preferable because it would provide: * consistent casting and operator semantics * better support across drivers, ORMs, FDWs, and extensions * a standardized ecosystem approach rather than fragmented custom types The lack of native support makes Postgre less suitable for workloads involving nanosecond-resolution datasets such as market microstructure research. Thanks Alex Malek --00000000000002c1c50652459a5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Hackers,


=
Postgres temporal types (timestamp= , timestamptz, and time= ) currently lag behind much of the analytical ecosystem in lac= king native nanosecond precision support.

Modern analytical an= d financial ecosystems increasingly require the ability to store and proces= s nanosecond-resolution timestamps regardless of the precision of the local= machine clock.


Nanosecond timestamps are already commo= n across:


* Parquet (TIMESTAMP(NANOS))

=

= * DuckDB (TIMESTAMP_NS)

* ClickHouse (DateTime64(9))

* Oracle TIMESTAMP precision up to = 9 fractional digits

* SAS datetime values with nanosecond precision=

* Pandas / NumPy (datetime64[ns])


In pr= actice, the lack of native PostgreSQL support forces applications into work= arounds such as:


* separate "nanosecond remainder&= quot; columns

* bigint epoch-nanosecond encodings

* custom/community temporal extensions e.g. https://github.com/optiver/timestamp9<= /p>

Additionally native support would be preferable because it wou= ld provide:


* consistent casting and operator semantics=

* better support across drivers, ORMs, FDWs, and extension= s

* a standardized ecosystem approach rather than fragmente= d custom types


The lack of= native support makes Postgre less=C2=A0suitable for workloads invol= ving nanosecond-resolution datasets such as market microstructure research.=

Thanks


Alex = Malek
--00000000000002c1c50652459a5a--