drob

Everything is denormalized into an array so we can evaluate funnel queries quickly, with no joins.

Correct -- they handle the idiom more gracefully in the context of an array-backed list, not an array. I elided the two as postgres arrays don't quite fit cleanly into either. (For example, evaluating arr[i] is O(i) for postgres arrays of variable width types.)

Such an interesting direction. Replication at the level of individual tables would be killer!

No, this isn't an issue for fixed length types, although you're still better off using unnest instead of explicitly indexing into them.

Query performance is critical. Insert perf is a comparatively minor concern.

Even so, there are a few factors to consider:

- Half second dedupes are for users with 100k+ events, which is <<1% of them.

- We batch events for ~5s before adding them to the cluster, so we aren't deduping for every event -- only once per ~5s of events per user.

If this becomes an issue, we can remove the deduping from normal operation and only call it when we're backfilling / updating events. Even so, we still need this function to exist, and the 100x performance improvement is very helpful.

I guess we could do it with hstore. I wonder what sort of performance I'll get on it for a hashmap workload. Hmm...

Yes. Our schema is fully denormalized, which is particularly important for performance on funnels. (See heapanalytics.com/features/funnels)

In particular, to compute where a user drops off in a funnel, I need to scan one array from left to right, and I don't need to do any joins. This shards very well, since all of a user's data lives on one shard, and most of the queries are aggregations, which are simple to reassemble from subqueries.

For now, the following works for us:

- For plpgsql functions that are required by app queries, we just roll them out when we write them / when they change (via ansible).

- For plpgsql functions used in jobs, the job just reloads the relevant plpgsql functions on the relevant DBs before they start doing anything. (It's a little wasteful, but not in a way that matters for now.)

- The UDFs we've written in C don't change too often, but we deploy them manually when they do.

What are some of the headaches you've had in managing stored procs? How often is your app code changing / requiring new ones?

Augh, I needed a hashmap in plpgsql last week! It's the worst. Best I could come up with was an awful hack in which I left stuff in a table with columns (key, val, invocation_code), where the third is a UUID specific to the invocation of the function. (Disgusting! I'm not proud of this.)

I'd pay (one upvote) for a blog post with a better way to do this. If one doesn't exist, this might call for a postgres extension.

Along these lines, I recommend installing New Relic server monitoring on all your EC2 instances.

The server-level monitoring is free, and it's super simple to install. (The code we use to roll it out via ansible: https://gist.github.com/drob/8790246)

You get 24 hours of historical data and a nice webUI. Totally worth the effort.

Agreed. One can learn a lot of practical postgres from camping out in there.

It's also where I found out about a handy tool for demystifying EXPLAIN output: http://explain.depesz.com/

Yup! This is the basis for Fourier analysis: http://en.wikipedia.org/wiki/Fourier_analysis

In general, I agree that building up can harm the character of a neighborhood, but this is often presented in the context of SF and Oakland as a false choice.

The difference between skyrocketing prices and stable ones is on the order of 3,000 new units per year, not 30,000. This is a goal we can hit with skyrises restricted to one part of town, or with three family homes in place of a lot of single family homes, or in a number of other tasteful ways.

It's not as if 500,000 techies are moving to Oakland at once. It's a slow trickle, but, with a fixed supply, prices spike.

Yup! Customers with <25k monthly visits won't be charged anymore.

The hope is that we can make this work for content sites case-by-case with the enterprise tier.

Agreed that this is still not ideal for medium-sized content sites, though a lot better than the old pricing model, which charged by the user (as opposed to the visit) and thus was a total nonstarter for them. We usually don't suggest sampling, because we do think there's value in using Heap for analysis at the top of the funnel.

Hacker News, what happened to you?

Father time has been cruel to you. Where once was a thriving community of armchair intellectuals eager to share their thoughts on Edward Snowden, Hyperloop, and the latest Snapchat valuation, now there is pixelated pornography.

Excuse me?

This exact behavior happened all the time when Steve Jobs ran Apple. Remember Google Voice, or the countless other apps that Apple banned from the walled garden for whatever reason?

If anything, this is evidence that Apple hasn't changed.

It's not quite that simple. Building up can ruin the character of the neighborhood, which is often a big part of the allure.

I do think we're chronically underbuilding in a lot of places (SF being an extreme example), but the existence of steel and elevators is not a panacea for the "gentrification problem".

I swear this article comes out again every two weeks.

That's fascinating if true, since the power to tax is the power to destroy. I don't see a clean division around a domain on which a retroactive tax is justified.

I had a hard time coming up with a good citation for this. Retroactive taxes seem to be legally controversial whenever introduced, and they're usually retroactive only to the beginning of the year introduced. Could you point me towards a better link?

We (Heap) would use Manchuria if you were to open source it. We currently have a multi-tab spreadsheet. My previous employer had an awful Salesforce system which was about as fun as eating sand.

You might even get a PR or two. :)

There's also a general disdain for the poor, rooted in just-world fallacy. As American politics would have you believe, the poor can't be trusted with cash. "They'll just spend it on drugs and plasma TVs!" Thus, the only politically salient form of aid to the poor is in the form of vouchers for specific things, e.g. food and medicine.

This is dogma on the right, but it echoes surprisingly often from the left as well.

Not to mention this does away with all the administrative overhead of the dozens of piecemeal welfare programs we have in the US. Rather than whitelisting narrow sets of allowed expenditures and making people prove that they're poor for each program, I suspect giving people an income that allows them to live decently without all the red tape and attached strings will make for a much more efficient way to fight poverty and improve quality of life.

That said, I don't think a basic income experiment with a successful outcome would cause us to take the notion seriously in the US.

Portugal's decriminalization of drugs in 2001 comes to mind. By all accounts, it was a great success, which we've largely ignored. The dozens of countries with single-payer health care systems that deliver better care for far less money are another regrettable example.

Here's hoping Switzerland undertakes what looks to be a fascinating experiment.

Ah, fantastic. The only thing missing from the global warming "debate" was a party that heavily benefits from a melted arctic.

That's different. For most software and movies, people not reading legalese isn't the core of your business. You make money on people buying your DVD, not on gotchas buried in license agreements. (Or, at least, I hope.)

JustFab is different. JustFab's viability depends on people not reading the fine print on the side. As I understand it, their "VIP Program" is their main differentiator.

If you seem like you'd describe your customers as "suckers", I don't want anything to do with you or your business.

But there's no value in closing the loop. If postgres circular replication works this way, then a -> b -> a works the same way as a -> b, so there's no new capability here.

Cute: "Incidentally, this also makes it possible to set up 'cycles' where replication is going in a circle. Whether that's a feature or a bug depends on your perspective."

Is there any context in which it would make sense to set up circular replication? This would necessitate that all of your nodes be read-only, so I'm not sure what there would be to replicate.

In any case, a bunch of these new features are hot. Particularly excited about fast failover and custom background workers.