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 1s9jbO-004fBP-Cg for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 10:53:47 +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 1s9jbL-00FkDn-Uk for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 10:53:43 +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 1s9jbL-00FkDc-Jp for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 10:53:43 +0000 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s9jbJ-001R9n-5Z for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 10:53:42 +0000 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2e724bc46bfso38730731fa.3 for ; Wed, 22 May 2024 03:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716375219; x=1716980019; darn=lists.postgresql.org; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=LMFzGgaJu6ssp7lT9Ibuwh1DT68pz/sPLRU4Cx+6CQY=; b=VoRqSsurXDIJrUZ1Ygge3lJ4gr1rrBtcEnFN/WkWc5FvGe+T/vRQTkg9L1Orxys7ha sbC6PfOyC5pMz6edpRBR/G1kfI12CqvDh4UOBZK7W85rApwqgue1HD3DjinIJ3DhyIrs OAU4IZHwFu0iTE23g4yjbgiVIod0a9ZK4YSgUZFdd6yVWHXguuXm0DSnAOO17/HP3UCs Svedlv2S6RPXNjopoeSBGYZ7N1IhdNLyksXBUCVlqSd59zBWsLQAShg5yMYdOwLDI5HH W+hwvE5OG/xgBhoZzfMvWhk9TNY1Aj9lklpyp/56cUnCz/hMvUBXIcz/++rMMFsUOcJe Psjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716375219; x=1716980019; h=cc: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=LMFzGgaJu6ssp7lT9Ibuwh1DT68pz/sPLRU4Cx+6CQY=; b=qJ0bxyWTvr6Tj2/ak/k8pHx8F8XUK0xMdLG6lwbZmoLjaAI2qODa62UdVYlGkoguKq W/YB2caFbZD21yxZStNB55ymGsoAOHI/JrVa5ko0pvDEZOGmIvqOGkZU6gZP1LEiV6p/ baUBda4mS96BOxM9OqPWqFNCbBNx7Fwt43DHPtcm7bX2I4HfKOAXFAR/qR0yWHAnXLFM Ez/3cMQELts0uHAOkU59tzKDhBECcTtieGbeQAx6xHkrXP7iooY5nvzO/R8FteZlbkyR TZl6aBr2twBTYRX0Fh0t/tnNjJ3yiKAj41tW+iGbHoDCaMQv4rRZy0kLCqXnaM927yd8 5EDQ== X-Gm-Message-State: AOJu0YyWYLD3fGHyRylF6QsmrtgjO/xB/PAgmdXmo9jZ1Gxxbxa1O0JE ybOz17YyQavSzISavPdrc6UKHWVMyxj7cnxsbMuprU5sPwVL0QvgCJu9zITfrXoXNZujVUCd9fz yl7UprC9j7QOyS32aXG0XzBJ7io/PhNx0 X-Google-Smtp-Source: AGHT+IEGsmI4YmRUlhuyw0MrJaSMD9v+nvb+vtBnM/i0PQSCufJSUhkibGfPnKjDlciuq1ybak1vw2hsff+uaFsoyow= X-Received: by 2002:a2e:9e9a:0:b0:2da:802b:2154 with SMTP id 38308e7fff4ca-2e9494bdd75mr10179781fa.16.1716375219039; Wed, 22 May 2024 03:53:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: o1bigtenor Date: Wed, 22 May 2024 05:53:02 -0500 Message-ID: Subject: Re: Regarding use case of epoch to generate nanoseconds precision Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003b8433061908bf51" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003b8433061908bf51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 22, 2024 at 4: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. > > Not a postgresql expert but - - - I'm wondering how you actually plan to implement this nanosecond timestamp? You will be working in an area where you will need some extreme corner case equipment for all items in the system. Not saying that measurements in this area can't be done rather that you will have internal ambiguities in your accuracy (network timing for one at the very least). Good luck --0000000000003b8433061908bf51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 22, 2024 at 4: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.


Not a= postgresql expert but - - - I'm wondering how you actually plan to imp= lement this nanosecond timestamp?
You will be working in an area = where you will need some extreme corner case equipment for all items in the= system.
Not saying that measurements in this area can't= be done rather that you will have internal ambiguities in your
<= div>accuracy (network timing for one at the very least).
Good luck

--0000000000003b8433061908bf51--