Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
srcreigh
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
52 ms
·
541.
▲
by
srcreigh
4y ago
Yeah, webview doesn't seem to have support for saving the JS VM and DOM to disk. Maybe a custom implementation could do this, but it may also quite slow. If I were you, I'd try a few different browser apps which don't use Web
542.
▲
by
srcreigh
4y ago
Even the worst recipe sites often have a "Jump to recipe" button to skip past the story and ads. pihole works decently well to stop ads from loading on mobile, speeding up the site and avoiding janky movement of the copy as ads lo
543.
▲
by
srcreigh
4y ago
Not really. CTEs are still optimization barriers after v12 if they're referenced more than once. That blog post is confused, but the commit message in the post is clear enough.
544.
▲
by
srcreigh
4y ago
The dbt site describes this as a simple example: select * from {{ref('really_big_table')}} {% if incremental and target.schema == 'prod' %} where timestamp >= (select max(timestamp) from {{this}})
545.
▲
by
srcreigh
4y ago
Nice this makes sense. Seems like storing connection_id in the table would make it difficult to look up data later? It seems like you could use (customer_id, seq_id) for similar effect.
546.
▲
by
srcreigh
4y ago
Can you provide an example?
547.
▲
by
srcreigh
4y ago
What is this debris? Where can I read more about this?
548.
▲
by
srcreigh
4y ago
Nice, TIL. The default value for work_mem is only 4MB though, and when I’ve seen materialized CTEs go wrong they’re usually using temp tables in the 10s or even 100s of MBs. Usually “with products as (select * from products where customer_i
549.
▲
by
srcreigh
4y ago
The other reasons are more important imo, and they aren’t really all tuning more ergonomics and simplicity. There’s a lot more edge cases when you use client-side generated IDs. You have to check if the ID is actually new to avoid security
550.
▲
by
srcreigh
4y ago
https://youtu.be/b2F-DItXtZs
551.
▲
by
srcreigh
4y ago
It seems like you're saying recursion is applying a sequence of functions to each other like f1(f2(f3(x))). This doesn't seem right to me -- it should be more like f(f(f(x)))
552.
▲
by
srcreigh
4y ago
Loops are isomorphic to recursion
553.
▲
by
srcreigh
4y ago
Thanks for sharing, Super cool. I wishlisted and downloaded the demo.
554.
▲
by
srcreigh
4y ago
B-trees are self balancing so I don't think there will be bloat. But if you insert towards the end of an index a lot, the right-side of the index will more likely be in cache which makes it a lot faster. If you inserted randomly then y
555.
▲
by
srcreigh
4y ago
The important factor is # of pages on disk that need to be retrieved. Secondary indexes (aka every index in Postgres) have to lookup the primary storage as well. If you use a primary key index to pull 100 rows, if the rows aren't clust
556.
▲
by
srcreigh
4y ago
Yeah I always mix these up. Thanks
557.
▲
by
srcreigh
4y ago
Covering indexes are different. You’d have to have a 2nd unique index which has all the rows from the table. A lot of large datasets would benefit from auto clustering but can’t handle 2x the storage for the same data.
558.
▲
by
srcreigh
4y ago
CTEs should not be materialized by default (latest PG if you reference a CTE more than once it stores intermediate rows on disk and disables indexes and causes a lot of trouble.) I’d love to see B-Tree primary storage option. Aka store the
559.
▲
by
srcreigh
4y ago
Harder to copy and paste IDs. Discourages denormalization since every reference is 128 ~~bytes~~ bits. Reduced throughout for inserts since the primary index pages won’t all be in cache if the keys are randomized. Lose ability to use id as
560.
▲
by
srcreigh
4y ago
For me the contrast setting on a monitor is key. Low brightness does almost nothing but lowering contrast helps immediately.
561.
▲
by
srcreigh
4y ago
The savings are 1%, not 0.1%.
562.
▲
by
srcreigh
4y ago
I didn't expect to learn something new about sorting while reading this. It's really cool that you can do Merge Sort asymmetrically, which lets you use a scratch buffer only 1/4 the size of the original array.
563.
▲
by
srcreigh
4y ago
The king can put himself in check too, so the defender would have to cooperatively allow checkmate (instead of capturing the other pieces)
564.
▲
by
srcreigh
4y ago
I like this philosophy a lot! Would you mind reaching out to me? Email in the profile
565.
▲
by
srcreigh
4y ago
Is plasma fluid dynamics the most important hated obligation of astrophysicists?
566.
▲
by
srcreigh
4y ago
Not materializing lets Postgres push extra where clauses and join conditions into the CTE so this makes sense! Now you know why I spam all the “CTEs are amazing” threads about materialization (there have been 5 or so in the last few months)
567.
▲
by
srcreigh
4y ago
AS NOT MATERIALIZED is equivalent to using sub queries
568.
▲
by
srcreigh
4y ago
No, but this would make an incredible Postgres extension. (I’d also love one that lets Postgres use a covering index for primary storage. This can reduce data size and load less data off disk due to locality. MySQL has this by default and S
569.
▲
by
srcreigh
4y ago
Postgres has materialization options for CTEs. You can ask it to rewrite the CTE as a join via "WITH foobar AS NOT MATERIALIZED (...)". Alternatively you can force materialization by writing "WITH foobar AS MATERIALIZED (...)
570.
▲
by
srcreigh
4y ago
This is incorrect. If you use a CTE more than once in a query, Postgres will materialize that data into a temp table that has no indexes. If that CTE gets joined a lot, it will incur many O(N) searched through unindexed data. I've seen
More ›