phiresky

You're right. I've updated the hot_rank function to take a timestamp with time zone. Note that I haven't really tested this change in general, I've just been relying on the...

Hey @lazyguru, thanks for the info. That's interesting, because I wouldn't expect this change to break much since it just means Lemmy now sends and receives timestamps with time zone...

@laurencedawson @EricBAndrews @mormaer @aeharding might be interested

there's a few things that should probably happen here: * duplicates on `idx_activity_ap_id` should probably be logged as a warning at most (without huge stacktraces) * if idx_activity_ap_id triggers, the...

I would intuitively say that most of the reason for the slow response is not the triggers but rather the inline acrivity sending #3493. The reason is that the database...

My suggestion would be as follows: 1. Replace all expensive triggers with simple ones where possible. There's some triggers (e.g. `person_aggregates_comment_count`) that do aggregating queries where I'm not sure why...

Here's a full table of all triggers. :heavy_check_mark: means this trigger is probably ok, :interrobang: means this trigger is buggy and should be fixed, :x: means this trigger is too...

Here's an updated table after 0.18.3. The only remaining expensive trigger is community_aggregates_post_count, which is not expensive on INSERT, but is expensive on restore and delete. | trigger source |...

Yes, #3605 will (if bugless) make federation guaranteed reliable, up until the point where an instance is down longer than the clear-scheduled-task clears activities (currently 3 months). If it goes...

I was actually using the id column on sent activities on my (unfinished) experiment for a persistent and robust outgoing activity queue. So it would be helpful to keep for...