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 1s9iAF-004VPn-6n for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 09:21:40 +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 1s9iAF-00FCkT-3s for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 09:21:39 +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 1s9iAE-00FCkK-P1 for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 09:21:38 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s9iAC-001QcO-Hl for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 09:21:37 +0000 Received: by mail-ed1-x542.google.com with SMTP id 4fb4d7f45d1cf-573061776e8so9888770a12.1 for ; Wed, 22 May 2024 02:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716369694; x=1716974494; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=l/wHQN9YA4FoQsv9kUu4flOm3ga9qXGIxRqP0lBNwmU=; b=j/6X2IcYuHLYnGnPz7x2mdtowOExb1jzMBBCaLTon2O/U/4BsiZMTcOTpMvZCbLtdx DpNcoB9jDToGewJGjtxQrtsbPExuTHOwU2JMYMNIqxpVPYvAfeVcnXMdGy42BWEdec7J 4wwr9DxnduOmoD7NGqpvA5wN3HzgYx3TGkKf4UFcg9mNPPV2YPhL7LPuSDgc6tsht5aM XKmp+Cm2iXQslTSMBiC1nunVIHcyyyzNrus9450kyyWcgz1UI6eFZwwgCf8+16idqWPT lINcy18YwPEmbbi7Tc2+rd9HLEAfHvL3pjE5IQ3wtacj5jk7TnyyJC8TXY64noOZIaal me5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716369694; x=1716974494; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=l/wHQN9YA4FoQsv9kUu4flOm3ga9qXGIxRqP0lBNwmU=; b=Kq1CgF0/eDSoHTZkcjO3n3TU9gzZNOfaV527k5Rpaw2nE9/mROnlYzSrU4mf1Hm6J/ /kPDJB+eaZ9azR00qBeHp0J9k2JVWs+pmctYKeiGQ9CHYtXxn2QVsX1UxLTAxzxQQDmz dCATOlZxEZqFdREzn5PwwVm70m8dgWTnzw7woEHyxxNRfi2JFR/MJwRyXnnib5r8EwBK 7pOTU8e1ADz8G9JhBGzW68/on+ZLCftDq6nfaP+/5eYRWXeBZjuMTwljlmADrrvuOgJa snL1CZdajOHwZ2R2Q2oIPWdapA3Xm4zD+Adn/XjguQ/5siAWUOtPbcpeqwPnDNNqcd68 gjew== X-Gm-Message-State: AOJu0YyFxsREpy2aPV9djdT+pP8DGmeMrSMSvnuCRoAm6nQpEIB3NKNC uxdZ/BUPgFTcIEA+aXsL01Z7/fmutve+KIjFYWIOxM4B2pGJ2wQ5uTIrqX+ir5iitsiS8LDCFi+ zpDvgcaaEzjzXkDavlgWxP7BZvyf6TEbXAtbLvlI6Py9ouqIb X-Google-Smtp-Source: AGHT+IGc+gmP98xYLb2ssdJrwBZnw0dxBYaeGEWBdppRGGvGTKyD1oeiV2jFhm1oUm7OIzS7RvPdS9KYxOHlTFarDC8= X-Received: by 2002:a17:906:f757:b0:a5c:23f5:828f with SMTP id a640c23a62f3a-a622807c1f4mr84976666b.24.1716369694116; Wed, 22 May 2024 02:21:34 -0700 (PDT) MIME-Version: 1.0 From: Durgamahesh Manne Date: Wed, 22 May 2024 14:56:26 +0530 Message-ID: Subject: Regarding use case of epoch to generate nanoseconds precision To: pgsql-general@lists.postgresql.org Cc: "keith.fiske@crunchydata.com" Content-Type: multipart/alternative; boundary="000000000000ebd5540619077564" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ebd5540619077564 Content-Type: text/plain; charset="UTF-8" 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 => (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, but 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 --000000000000ebd5540619077564 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0=C2=A0

Postgres supports only u= pto microseconds (6 decimal precision).
How do we generate timest= amp with nanoseconds as rds postgres not supported=C2=A0timestamp9 extensio= n ?
Is there a way to generate timestamp with nanoseconds precisi= on on pg_partman with epoch without typecasting or with 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







--000000000000ebd5540619077564--