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.94.2) (envelope-from ) id 1s9oLz-005Is5-Cw for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 15:58:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s9oLz-000t9b-EF for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 15:58:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9oLz-000t88-2F for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 15:58:11 +0000 Received: from mail-oa1-x2a.google.com ([2001:4860:4864:20::2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s9oLv-001TUs-Rr for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 15:58:09 +0000 Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-23db0b5dd28so3639200fac.2 for ; Wed, 22 May 2024 08:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crunchydata.com; s=google; t=1716393487; x=1716998287; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tcel75V874HALxDDARdsHJrRN15/YV29v91pbbsKq7o=; b=qOuzd07sS6/3gYe5GuHOHacYDiQJrcSLh6tCsOjFce6I15H8A5gD0TR7nt5SnRuJUX cU+aEOyt2Q+eqJ70Pdq09l7ZGmYpfDaPK+WYn86cqHjrUXg1lUpOwr2pQhGZpkUYmPO9 U6X9+ZbIlLdmaLcs77LwsJOBMuaYWKIzOAcBYaT/WS7Bs18QVPwOfCDI1DPC85EmmAry 8QfpUyFpY5XcaO6MDGI9xJXFFncLxjRePIl9Vh1RbIQsqGZDQMiDCNPgk0Fp9+461js5 xrf9DSJHfSWUrC4cVJFGAW1cspC1rx2BWFKa5fAj8bkwBuICTGRh4aPo9XzZDVF/yqJ4 1FqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716393487; x=1716998287; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tcel75V874HALxDDARdsHJrRN15/YV29v91pbbsKq7o=; b=lP88OozyN6VoBwwszTM5gJXvPz0RlqIy8qf0wFsahbr2YlOYiOuDM8k5/iQGnpKOOG t7Y+cUcEwvlTyHAvQIZ9ZKCZYVCXZyp01CxagX0cQ5rQT+jZ+pPSXsfzbaoIdSeRWFuM u1nf1ZexfjvCEwJ7ZZNACxLxuZUtRCAQdAMGNeAPOcg2L/TXmaWUdEZnBAXKVBT3561w buGZ/MWanehOBFhS6ym1dE2Nq5vozg7GtCLO4e4FDGSi/REQUXChstktfNP338N39+n6 oFabhvXuEo/rbgVhVU4fUlB22GKhORdknwGz9PoihW3yGDRtge450dU9tJJPrZfJbzq9 BAzg== X-Gm-Message-State: AOJu0Yw4NeddcpIgTkQ98/N5cFOoxrPCrQDCbvD3+5YFXRrsZvVymD5k ZoOkM1lB6WtJ3mjK54XJM6FCUW+Qrt5mojh4kDQUF/imJRy7f7nctDiozwxdgsWW5RXyIvWOyHo eHvK4b1mvc/c33YmPZSEPKgJ/l+JlUyItBURc2CuADkL65VXWYnc= X-Google-Smtp-Source: AGHT+IHZ23uWbHcYjOPtpllRzXBIC3xtxjx+sdQ1ZQxzkMTzmyIU/EdrsWkMrciPJcK8vWCAGwdIOAFIB9Pq8+728nk= X-Received: by 2002:a05:6870:d14f:b0:24c:647b:dfa with SMTP id 586e51a60fabf-24c68aae308mr2829169fac.5.1716393487056; Wed, 22 May 2024 08:58:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Keith Fiske Date: Wed, 22 May 2024 11:57:40 -0400 Message-ID: Subject: Re: Regarding use case of epoch to generate nanoseconds precision To: Durgamahesh Manne Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000175c7c06190d00f3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000175c7c06190d00f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 22, 2024 at 5:21=E2=80=AFAM Durgamahesh Manne wrote: > Hi > > Postgres supports only upto microseconds (6 decimal precision). > How do we generate timestamp with nanoseconds as rds postgres not > supported timestamp9 extension ? > Is there a way to generate timestamp with nanoseconds precision on > pg_partman with epoch without typecasting or with typecasting ? > > p_epoch =3D> (to_timestamp(control column)) > Here what is the control column? > How to run it with the create_parent function of partman? > > Here as per the pg_partman doc > p_epoch - tells pg_partman that the control column is an integer type, bu= t > actually represents an epoch time value. Valid values for this option are= : > 'seconds', 'milliseconds', 'nanoseconds', and 'none'. The default is > 'none'. All table names will be time-based. In addition to a normal index > on the control column, be sure you create a functional, time-based index = on > the control column (to_timestamp(control column)) as well so this works > efficiently. > > > Regards, > Durga Mahesh Manne > > The option in pg_partman simply multiples the normal epoch value by 1000000000 then converts it with to_timestamp(). https://github.com/pgpartman/pg_partman/blob/master/sql/functions/create_pa= rtition_time.sql#L119C64-L119C74 I'd already had the millisecond option in partman for epoch, and someone requested nanosecond precision. It was easy to add the option so I did it for them, and anyone else that may find it useful. How you actually implement that level of time precision in an epoch value in your environment is entirely up to you. --=20 Keith Fiske Senior Database Engineer Crunchy Data - http://crunchydata.com --000000000000175c7c06190d00f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 22, 2024 at 5:21=E2=80=AF= AM Durgamahesh Manne <mahes= hpostgres9@gmail.com> wrote:
Hi=C2=A0=C2=A0

Post= gres supports only upto microseconds (6 decimal precision).
How d= o we generate timestamp with nanoseconds as rds postgres not supported=C2= =A0timestamp9 extension ?
Is there a way to generate timestamp wi= th nanoseconds precision on pg_partman with epoch without typecasting or wi= th typecasting=C2=A0 ?

p_epoch =3D>=C2=A0=C2=A0 (to_timestamp(control column))
Here what is the control column?
How to run it wit= h the create_parent function of partman?

Here as p= er the pg_partman doc=C2=A0
p_epoch - tells pg_partman that the c= ontrol column is an integer type, but actually represents an epoch time val= ue. Valid values for this option are: 'seconds', 'milliseconds&= #39;, 'nanoseconds', and 'none'. The default is 'none&#= 39;. All table names will be time-based. In addition to a normal index on t= he control column, be sure you create a functional, time-based index on the= control column (to_timestamp(control column)) as well so this works effici= ently.


Regards,
Durga= Mahesh Manne


The option in pg_partman simply m= ultiples the normal epoch value by 1000000000 then converts it with to_time= stamp().


I'= ;d already had the millisecond option in partman for epoch, and someone req= uested nanosecond precision. It was easy to add the option so I did it for = them, and anyone else that may find it useful. How you actually implement t= hat level of time precision in an epoch value in your environment is entire= ly up to you.

--=
Keith Fiske
Senior Database Engineer
Crunchy Data = - http://crunchydata.c= om
--000000000000175c7c06190d00f3--