pvh

16 ms·

61.
by pvh 12y ago
Yep.
62.
by pvh 12y ago
Awesome to see this. We have a similar tool we built here at Heroku called "rearview" but right now the source has a bunch of heroku-specific cruft like out oauth service baked in. We should release it too. Intelligent pager analy
63.
by pvh 12y ago
Cool concept. I'm not a huge fan of normalizing out the underlying data into pseudorelational tables. Reconstructing trees in Postgres is a little gnarly on larger tables but it's definitely neat to see more people trying to combi
64.
by pvh 12y ago
Pricing is super hard - I love this framing of the problem but there are so many other good references. I'm also a big fan of Neil Davidson's very brief book "Don't just roll the dice": http://neildavidso
65.
Managing Pricing(heavybit.com)
88 points by pvh 12y ago|22 comments
66.
by pvh 13y ago
XL dynos use the same router as everyone else.
67.
by pvh 13y ago
That's fair enough. It's worth noting that Hitoshi Harada, the original author, is a long time contributor to the core project.
68.
by pvh 13y ago
Postgres is an extensible database. That's the beauty of the project. I don't think you'd say "well, Ruby is awesome but web application development support comes from a third-party project, not the standard library."
69.
by pvh 13y ago
Those of us at another arm of Salesforce ( http://postgres.heroku.com ) are incredibly honored to have Tom join the family. The team they've put together there is doing some really exciting work.
70.
by pvh 14y ago
There is a saying among the best, most wonderful kind of people in the Ruby community: "We are nice because Matz is nice." If you've had different experiences, I'm very sad to hear that!
71.
by pvh 14y ago
The Instagram guys said they didn't actually bench using a UUID + created_at column when they spoke at SFPUG, they just used their approach because it was recommended to them and seemed to work. That said, it is a pretty awesome robust mech
72.
by pvh 14y ago
Sorta. It can be handy for guiding the optimizer away from a bad optimization choice but that's really a bad habit to get into.
73.
by pvh 14y ago
awesome, would you generate a PDF of my slides then?
74.
by pvh 14y ago
Glad you enjoyed the slides. I put a comment about navigation on the first slide. Hopefully that will help.
75.
by pvh 14y ago
Some of it is in the standard, some of it is PG specific. MySQL is pretty terrible and doesn't support any of it that I'm aware of. I expect Oracle has their own versions of much of this stuff, but I've made it a hobby in my life to not lea
76.
by pvh 14y ago
> though I really wish Postgres could get native online clustering. Tell the community - pg_reorg could be cleaned up, improved, and merged into core... and should be!
77.
by pvh 14y ago
Postgres does not store keys in primary key order, actually, but in write order. This is an artifact of the MVCC model. There is a CLUSTER command that would do what you describe above, but it is (effectively) useless since you can't really
78.
by pvh 14y ago
Using Showoff, like this: https://github.com/pvh/postgres-bits
79.
by pvh 14y ago
The biggest reason is that your IDs become universally unique - across shards, across database recoveries, rollbacks and session problems, you name it. These are all the kinds of things that can happen over the lifespan of a dataset. In Pos
80.
by pvh 14y ago
Navigate with arrow keys - these are slides from a talk I gave.
81.
by pvh 14y ago
Eh, I wouldn't recommend going this route. I'd go down the pgbouncer road instead.
82.
by pvh 14y ago
Data Dep't here. Postgres scales great on Heroku, AWS, and in general. We've got users doing many thousands of query per second, and terabytes of data. Not a problem. The issue with the number of connections is that each connection creates
83.
by pvh 14y ago
Mongo's probably still got the edge as a JSON store overall, but definitely check out the new JSON object dereferencing functionality coming in 9.3. There's a Russian indexing posse consisting of Oleg, Teodor, and Sasha who have been lookin
84.
by pvh 14y ago
Running apps are not affected, but your ability to do development is. The threat vector affects app compilation, not app execution/scaling, which doesn't touch the tainted rubygems.org repositories.
85.
by pvh 14y ago
You know what would make this faster? If you ran your tests inside Heroku as well. Then you wouldn't have all the network round-trip time and you'd be test in the same environment you go to production on.
86.
by pvh 14y ago
By all means.
87.
by pvh 14y ago
We don't provide server-side connection pooling today, no. It adds too many gotchas to be universally applicable and has had too few use cases to reach the top of our TODO list. We do hear from time to time from people who want it though, s
88.
by pvh 14y ago
We figure reliability of your database as one of our chief missions. To that end, we prefer not to do anything which could even remotely be a possible cause of operational issues. Since changing over to a new version is easy, we tend to let
89.
by pvh 14y ago
Absolutely. Basically, as long as your app is running somewhere with Very Good Latency to your database, this can be a fine pattern. In practice, this means if the data center is also in Ashburn, Virginia, and better yet, has a DirectConnec
90.
by pvh 14y ago
That's a fair criticism - thanks for the rebuttal. (Edit) Also - what kind of visibility are you looking for that we don't offer today? Please feel free to email me (my email is rather guessable) with whatever you have.

More ›