Postgresql getting last row without use of sequence or timestamp - postgresql

Question

At job, we are using a program which is writing all its values in a single table.
Some of these data can be for instance settings of a machine and it can happen that these data does not change for a whole month. The program writes only on data change.
So getting last point of data was always with something like:
SELECT value
FROM table
WHERE tag_id = id
SORT BY timestamp DESC
LIMIT 1;
If I understand correctly in this case it will look up the whole table, which means longer execution time and wasting resources.
I will have multiple of these functions running  and spamming server which is not acceptable.
I can not use last value of sequence of id as multiple values are writing in same table sharing same id sequence. So we are talking last row in table from certain tag_id since those are different for different data and not last row of table.
I was looking at fetch but from my understanding it will take same time as limit.
I was thinking along of FOR LOOP going back in section of time till 1 value is not found. And maybe later optimizing with temporary table where last value timestamp is written and then searching since that time stamp and if none found using last value.
But i was wondering if there is a better/faster more optimized way in Postgres.

Answer 1

If you want to speed up the query, you should create an index. Switching to a LOOP is almost always a recipe to make things slower.
To support your query, create the following index:
create index on the_table (tag_id, "timestamp");
On a test table with a million rows and 1000 different tag_id values, the execution plan looks like this:
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.42..1.39 rows=1 width=53) (actual time=0.066..0.067 rows=1 loops=1)
Buffers: shared hit=1 read=3
I/O Timings: read=0.051
-> Index Scan Backward using test_table_tag_id_timestamp_idx on test_table (cost=0.42..924.66 rows=953 width=53) (actual time=0.066..0.066 rows=1 loops=1)
Index Cond: (tag_id = 41)
Buffers: shared hit=1 read=3
I/O Timings: read=0.051
Planning:
Buffers: shared hit=57 read=1
I/O Timings: read=0.011
Planning Time: 5.717 ms
Execution Time: 0.089 ms
You can see that Postgres only needed to read 4 blocks (shared hit=1 read=3) to get the row in question. This will be pretty much constant even if the table grows.
Note that the high planning time is caused by the buffer reads to fetch the table's metadata because I ran the query right after creating the table and inserting the rows. If the query is run for a second time, this pretty much vanishes as the meta data will be cached and the planning time will go down to substantially less then one millisecond.