Positions table growing very large since 2025

[vincep5]

I noticed a while back my drive detail queries were very slow. I peeked into the db and saw my positions table was over 19million rows!
I've been logging since Oct 2022 and then added another Tesla in 2024. I went deeper and got queries on the number of positions rows per month and noticed something jumped in Jan 2025

Can someone give ideas on why this happened at that point?
I also have a screenshots of a random day and it shows a drive with multiple positions per second of a drive.

I had thought that the drive would only allow a data point every 2.5 seconds or longer by default.
I am running Teslamate 3.0.0 and my Tesla Account does not have any other 3rd Party Access granted

[eliluong]

I have the same data resolution. There must be some minimum threshold change that pushes new data to streaming API. If I drive at high speed, I can see up to five updates per second. My car is 7 years old, logged about 60k miles, and I have 15mil rows. A data snippet from 2024 shows the same high resolution.

[vincep5]

I'm starting a clean up process that will take care of some of the bloat in the positions table. I'll share the query that AI helped with
It will clean up records that have more than 1 entry per 2 seconds. You can adjust the PARTITION BY car_id, floor(extract(epoch from date) / 2) to 4 or whatever amount of seconds you wish

DELETE FROM positions
WHERE id IN (
    SELECT id
    FROM (
        SELECT id,
               -- Identify rows that are NOT the first in their 2-second bucket
               row_number() OVER (
                   PARTITION BY car_id, floor(extract(epoch from date) / 2) 
                   ORDER BY date ASC
               ) as row_num
        FROM positions
        WHERE date >= '2025-01-01' AND date < '2025-02-01'
    ) AS sub
    WHERE row_num > 1
)
-- The Shield: Protect rows linked to charges or drives
AND NOT EXISTS (SELECT 1 FROM charging_processes WHERE position_id = positions.id)
AND NOT EXISTS (SELECT 1 FROM drives WHERE start_position_id = positions.id OR end_position_id = positions.id);

It was recommended to do a VACUUM ANALYZE and a REINDEX TABLE after all was done with.