Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Rob Sargent <robjsargent@gmail.com>
Mime-Version: 1.0 (1.0)
Subject: Re: Convert date and time colums to datetime
Date: Sun, 19 Oct 2025 13:40:59 -0600
Message-Id: <54588BDB-434E-42C4-A412-CC0F5A3DE7FB@gmail.com>
References: <a72e49a3-d057-7cf9-f21f-983c84824e64@appl-ecosys.com>
Cc: pgsql-general@postgresql.org
In-Reply-To: <a72e49a3-d057-7cf9-f21f-983c84824e64@appl-ecosys.com>
To: Rich Shepard <rshepard@appl-ecosys.com>
Archived-At: <https://www.postgresql.org/message-id/54588BDB-434E-42C4-A412-CC0F5A3DE7FB%40gmail.com>
Precedence: bulk


> On Oct 19, 2025, at 1:08=E2=80=AFPM, Rich Shepard <rshepard@appl-ecosys.co=
m> wrote:
>=20
> =EF=BB=BFOn Sun, 19 Oct 2025, Laurenz Albe wrote:
>=20
>> That depends on what you do with the table.
>=20
> Laurenz,
>=20
> That makes sense.
>=20
>> Are your SQL statements simple and natural with the current design?
>> Then stick with what you have now.
>=20
> That's what I'm going to do. I was curious when a timestamp column was mor=
e
> efficient, or otherwise preferred, since only a couple of my databases hav=
e
> a table with both date and time. And neither has many rows, but one could b=
e
> quite large some time in the future.
>=20
> Thanks very much,
>=20
> Rich
>=20
I think you have to ask why those values were separated in the first place. =
For instance if they are thought of as a pair in most queries then an altera=
tion might be in order. There can be a large one time cost if these tables o=
ccur in a lot of separate sql calls in the business logic.

>=20