Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
malisper
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
74 ms
·
361.
▲
by
malisper
10y ago
> Competitive programming is great. But why hold it in direct proportion to ability to build products? Because it's quick to test how good someone is at competitive programming, it's easy to grade everyone consistenty, and it (
362.
▲
by
malisper
10y ago
In hindsight, it's obvious that everyone should use multiple DNS providers. DNS failing has almost never been an issue before, so it's something that a lot of companies didn't expect and were unprepared for.
363.
▲
by
malisper
10y ago
There are a lot of people who have actual experience, who can't code.
364.
▲
by
malisper
10y ago
It's only the first step in the interview. If you get past Fizzbuzz (a lot of people can't), they go more in depth about things that actually matter.
365.
▲
by
malisper
10y ago
Is there a way to index JSON in MySQL without creating one index per unique field?
366.
▲
by
malisper
10y ago
I thought Uber uses Google Maps. When I open the app, I see "Google" in the bottom left.
367.
▲
by
malisper
10y ago
I think there is already a patch for Postgres 10 that runs the vacuum on insert only tables. While not completely solving the problem, that will be helpful.
368.
▲
by
malisper
10y ago
> Index-only scans for partial indexes This one is huge for my company. Almost every single query of ours could use an index-only scan, but the planner would never choose to perform one because of the weirdness around partial indexes. We
369.
▲
by
malisper
10y ago
Yes, in your case you did the right thing.
370.
▲
by
malisper
10y ago
> Now the most common solution to less row lookups would be using an index. We could create one on created_at and call it a day. But we’d probably only see a very small speedup. Why is that? As we’re not interested in “the last 14 days
371.
▲
by
malisper
10y ago
There's an easy way to find out - measure. I'm curious as to what the performance looks like when it's properly tuned.
372.
▲
by
malisper
10y ago
To the authors: You should try set track_io_timing = on before running the query. That will show you the actual amount of time spent on i/o. Additionally, if you are using RAID, and haven't tuned it yet, you should try increasin
373.
▲
by
malisper
10y ago
And what about time partitioning? Do you have a job that creates new tables and merges old ones together?
374.
▲
by
malisper
10y ago
That get's into our indexing strategy which Dan talks about in this talk[0]. Currently our tables aren't completely insert only, so a BRIN index wouldn't work for us, as one row in the wrong place can cause a huge amount of e
375.
▲
by
malisper
10y ago
How do you manage the partitioning? We've thought of partitioning events (by time and/or by type of event) but we haven't found an easy way to migrate to partitioned tables and we aren't exactly sure how we would maintai
376.
▲
by
malisper
10y ago
There's two parts to it. We first split up data by different customers. At some point customers get big enough that having a single table is slow. Once a customer reaches a certain size we split up the end users into ranges and have s
377.
▲
by
malisper
10y ago
I have two one on one meetings each week which together wind up being one to two hours a week. The CEO of my company's philosophy is that having more than two engineers meet together is usually a waste of time. This is for a small comp
378.
▲
by
malisper
10y ago
Most of our queries depend more on the time of the events rather than the user the events belong to. For example, let's say you want to know how many users signed up on Monday and logged in again before Friday. That query would fetch a
379.
▲
by
malisper
10y ago
Yes, the person I was replying to was asking about what to do if you don't have jsonb.
380.
▲
by
malisper
10y ago
My guess - it's slightly non-trivial and people are working on more important things.
381.
▲
by
malisper
10y ago
Postgres does use a variation of lz when using TOAST. TOAST is the technique Postgres uses to store attributes that are too big to store with the rest of the row. Unfortunately, TOAST only works within a single attribute, it doesn't wo
382.
▲
by
malisper
10y ago
If you want to allow user-defined fields in a relational database, your realistic are either EAV or stuff json into a text column. EAV, if done extremely carefully, can be a good solution, but 99% of the time, it's going to be a huge p
383.
▲
by
malisper
10y ago
> Protip: Use the planner config settings[1] (one of which is mentioned in this article) with SET LOCAL in a transaction We've wanted to do this but the last I checked, Citus, the software we use to shard our postgres databases, isn
384.
▲
by
malisper
10y ago
A while ago I came across this thread[0] in which Tom Lane brings up the fact that statistics are kept on functional indexes. I can't remember why, but for some reason I couldn't get the planner to do what I specifically wanted. I
385.
▲
by
malisper
10y ago
This is roughly EAV. EAV is where you have a with a schema: entity_id | attribute_id | value EAV is typically considered to be an anti-pattern for several reasons: it becomes very expensive to rematerialize a entity with all of its
386.
▲
by
malisper
10y ago
This is correct. Postgres keeps a bitmap in each row that designates which of the rows are null. Postgres initially allocates one byte for the bitmap so it will work for up to eight columns. Once your table has more than 8 columns, postgres
387.
▲
by
malisper
10y ago
A Gin index only helps with querying the data from the table. It won't help with making the proper join choice or with getting a bitmap scan between multiple indexes. Additionally, you are unable to query numeric values by an inequalit
388.
▲
by
malisper
10y ago
My bad. As of right now, we use jsonb to store all of the properties of events besides the user_id, the event_id, and the time of the event. We have lots of builtin properties which are stored in some events but not others (for example, the
389.
▲
by
malisper
10y ago
As of right now, our schema is literally: user_id | event_id | time | data where data is a JSONB blob that contains every other piece of information about an event. Currently, we get a row estimate of one for pretty much every quer
390.
▲
by
malisper
10y ago
At Heap, we allow users to send custom event properties through our API. Since we don't know what properties users will send in advance, we need to use something like JSONB to store them.
More ›