Neat! Seeing this I'm considering making a similar project that takes a search and drops the preview pictures. No post-video-watching suggest + no 1 minute video shorts + no clickbaity preview pictures + setting a watch timer or something like that might get me back on youtube.
You can try this addon (Unhook: Remove YouTube Recommended Videos Comments) as it does just that and more, my web yt is clean, I don't even have a feed thanks to this.
Personally, I tried pgtyped in a greenfield project but ended up switching to Slonik. Both are brilliant packages-- if you ever peak at the source of pgtyped it basically parses SQL on its own from what I could understand. The issues I had were-- 1) writing queries sometimes felt a little contrived in order to prevent multiple roundtrips to the database and back and 2) pgtyped gave weird/non-functioning types from some more complex queries. I've had better luck with Slonik and just writing types by hand.
I was curious so I tried it in postgres 13. Postgres, at least, uses the index to form a bitmap and scans that when aggregating in the first case (10% rows in the bitmap) and not in a second case WHERE "createdAt" BETWEEN '1990-01-01 00:00:00' AND '2020-12-31 23:59:59'; (100% rows in the bitmap, obviating the need for the intermediate step). I also tried ~20% rows (2019-2020) and the planner skipped the index.
'''
CREATE TABLE temp (id SERIAL PRIMARY KEY, amount MONEY, "createdAt" TIMESTAMPTZ);
CREATE INDEX ON temp ("createdAt");
INSERT INTO temp(id, "createdAt", amount) SELECT generate_series(1,1000000) AS id, NOW() + (random() * (interval '10 years')) - interval '10 years' AS createdAt, random() * 100::money AS amount.
EXPLAIN SELECT sum(amount) FROM temp WHERE "createdAt" BETWEEN '2020-01-01 00:00:00' AND '2020-12-31 23:59:59';
Aggregate (cost=10286.06..10286.07 rows=1 width=8)
-> Bitmap Heap Scan on temp (cost=2148.00..10033.48 rows=101032 width=8)
Recheck Cond: (("createdAt" >= '2020-01-01 00:00:00-05'::timestamp with time zone) AND ("createdAt" <= '2020-12-31 23:59:59-05'::timestamp with time zone))
-> Bitmap Index Scan on "temp_createdAt_idx" (cost=0.00..2122.75 rows=101032 width=0)
Index Cond: (("createdAt" >= '2020-01-01 00:00:00-05'::timestamp with time zone) AND ("createdAt" <= '2020-12-31 23:59:59-05'::timestamp with time zone))
And when running a longer query:
Finalize Aggregate (cost=14596.71..14596.72 rows=1 width=8)
-> Gather (cost=14596.49..14596.70 rows=2 width=8)
Workers Planned: 2
-> Partial Aggregate (cost=13596.49..13596.50 rows=1 width=8)
-> Parallel Seq Scan on temp (cost=0.00..12620.00 rows=390597 width=8)
Filter: (("createdAt" >= '1990-01-01 00:00:00-05'::timestamp with time zone) AND ("createdAt" <= '2020-12-31 23:59:59-05'::timestamp with time zone))
Buffer pool plays a big part. Very possible all the data is already in-memory, and for certain data sizes it'll be faster to just follow leaf nodes start-to-finish than it is to determine what pages you can skip.
Postgres buffer pool is a ring, and relies on "clock sweep" to decide what pages it can evict on each iteration. It has a shared buffer, and per-query buffers to eliminate shared buffer evictions (for costly queries). When doing index scans, worst-case the same page is being accessed in random order multiple times and it's evicted between those accesses so we end up with redundant disk I/O.
Bitmap scans ensure each page is only scanned once and in-order, so it's a great solution when you need more than an index scan but less than a full table scan (worth of data), not to mention multiple indexes can be combined into one bitmap scan.
If every page is already in memory, the query planner may pick plans that look sub-optimal if you factor in disk I/O but are otherwise very efficient in-memory.
Sweet! An MMORPG element would be the bees knees here. Years ago there was a similar (though-MMORPG) game called Diaspora from a small studio[1]. I still remember waking up at all hours of the night to play inconspicuously (without tying up the phone line). It was freeware and featured in PC Gamer. Eventually cheaters/bots overtook the game, literally DDOSing the thing as each "node" could only support maybe 50 ships because of how they were displayed in game (~5x10 grid or so). Ultimately, the studio didn't have a solid monetization strategy and the project disappeared off the face of the earth when its users spiked. They would have made a killing with micro-transactions, but online payments weren't ubiquitous then. Instead these poor devs spent all this time/money developing the game, maintaining the servers and fighting cheaters for free before the whole thing crumbled under its own weight. It lived on in clones (Rillaspora, Xiaspora and The Reunion) but they all died within a year or two.
I could be wrong but didn’t phoenix just switch to webpack from some other package manager? I guess that was 3ish years ago so a lifetime more or less in JS.
I think SQS was the first AWS offering. In that context “simple” means simple compared to other offerings of the 2000s/rolling it out yourself. I agree it’s a little convoluted for newcomers in 2021 although probably unintentional.
This is useful! Every so often Docker acts up or a Youtube video hidden in a tab somewhere or some silly mistake opens tons of Postgres connections on my M1. Previously the only cue was hitting the critically low power (10%?) at 6 hours instead of 12. Now there's this app. Thank you!
