x27;4GB' caused the planner to prefer the optimal index
updates_driver_id_time_idx.
Is increasing the DB's RAM the correct fix for this problem? It seems
to me that no matter how much cache is available, looking at the
(driver_id, time) index is always the optimal choice for this query.
Thanks,
Eric
iver_id on updates
(cost=0.11..302189.90 rows=443924 width=56) (actual
time=115.048..115.048 rows=1 loops=1)
Index Cond: (driver_id = 30132)
Buffers: shared hit=20376
Total runtime: 115.091 ms
It does seem faster than when having an index on just "time", but
still not opti
work in a certain direction?
I created this index and the query plans did not change.
--
Eric Jiang, DoubleMap
e...@doublemap.com | www.doublemap.com
K rows,
but uses ix_updates_time for drivers with more than about 300K rows.
Anything we can do to make it do the "right" thing? We are also
considering denormalizing the data and keeping a "cache" of the same
data in another table.
pgsql version: 9.3.14 and 9.5.3, already t
