Anyone ever encounter this? **Postgres Enterprise DB Advanced Server 11.5.12**

`sysdate()` (Oracle proprietary) results in a Seq Scan of, in this case, 4,782 rows: 

```
EXPLAIN SELECT p.id, p.practice
 FROM PatientStatistics ps
 INNER JOIN Patients p
   ON p.id=ps.patient
 WHERE ps.nextfutureapptdateservertime <= sysdate()
 ORDER BY p.id ASC;

Hash Join  (cost=799.81..1761.53 rows=4782 width=8)
   Hash Cond: (p.id = ps.patient)
   ->  Index Only Scan using patients_index3 on patients p  (cost=0.29..921.44 rows=15442 width=8)
   ->  Hash  (cost=644.11..644.11 rows=4782 width=4)
         ->  Seq Scan on patientstatistics ps  (cost=0.00..644.11 rows=4782 width=4)
               Filter: (nextfutureapptdateservertime <= sysdate)

```

Changing to `now()` or `current_timestamp` (SQL Standard) fixes the issue. Postgres is correctly using the Index:

```
EXPLAIN SELECT p.id, p.practice
FROM PatientStatistics ps
INNER JOIN Patients p
   ON p.id=ps.patient
WHERE ps.nextfutureapptdateservertime <= now()
ORDER BY p.id ASC;

Nested Loop  (cost=0.57..51.41 rows=17 width=8)
   ->  Index Only Scan using "patientstatisti_idx$$_0c9a0048" on patientstatistics ps  (cost=0.29..8.53 rows=17 width=4)
         Index Cond: (nextfutureapptdateservertime <= now())
   ->  Index Scan using patients_pk on patients p  (cost=0.29..2.52 rows=1 width=8)
         Index Cond: (id = ps.patient)

```

Interesting to note the different in output of those functions:

```
SELECT now();
SELECT current_timestamp;

15-JAN-20 09:36:41.932741 -05:00
15-JAN-20 09:36:41.932930 -05:00

SELECT sysdate();

15-JAN-20 09:37:17

```

Perhaps Postgres's Date Indexes are hashed using Datetimes that have Decimal portion. The planner sees it was passed a date that doesn't have Decimal, and it knows the Index's Keys won't line up accurately, so it backs off to a Scan to ensure the query delivers 100% accurate results.

I could find nothing about this online after a 30-minute Googling.