> Since virtually every value is going to be different, indexing and searching on that field is (almost) no better than having no index on the datetime field at

> Since virtually every value is going to be different, indexing and searching on that field is (almost) no better than having no index on the datetime field at all. Do you mean exact equality is rarely what you want because most of the values are different? Or are you talking about the negative effect on index size of having so many distinct values? I think the latter point could be quite database-dependent, eg. BTree de-duplication support was only added in Postgres 13. However, you could shave off quite a bit just from the fact that storing a date requires less space in the index than a datetime.