Live data from Hacker News

Viewing profile — tommyzli

tommyzli

HN member
Joined
Thu, Dec 21, 2017, 5:16 PM UTC
HN karma
132
Public activity
16 items

About tommyzli

No profile information was provided.

Recent public activity

  1. comment
    Comment #41344935

    Just last week I started hacking on a k8s operator for managing postgres roles, grants and databases. I really like the continuous reconciliation for this scenario, especially havi…

  2. comment
    Comment #38447896

    I'm curious to hear more about your troubles with alloydb. It's something I just started to test out at work

  3. comment
    Comment #35003282

    the last time I gave the Postgres operator space a serious look was about a year ago, and at the time the Zalando operator was far and away the most feature complete and mature. We…

  4. comment
    Comment #25931447

    Wow, I wasn't expecting such an in-depth response! It sounds like making user profiles a reference table would solve the cross-shard join problem, but what would the performance im…

  5. comment
    Comment #25920067

    1. You'll have to define "slow" - I have a 3TB table where an index only scan takes under 1ms 2. hot_standby_feedback is absolutely safe. I've got 5 hot standbys in prod with that …

  6. comment
    Comment #25913448

    Believe it or not these numbers are actually from _after_ me and some others spent a few weeks cleaning up our heavier queries

  7. comment
    Comment #25913110

    TIL, this is really good to know! Do you know offhand if this is a new feature, or have I just always been wrong

  8. comment
    Comment #25911554

    It's not in the post, but I answered this in a separate thread. RDS doesn't let us provision as many IOPS as we need. Apparently Aurora behaves differently, but I wasn't aware of t…

  9. comment
  10. comment
    Comment #25911403

    We are living life on the edge to an extent, but we have 5 hot standbys across AZs and regular backups + WAL archives to S3. May not be as durable as EBS, but it's enough for me to…

  11. comment
    Comment #25911123

    Apparently I'm living in the twilight zone because I have a vivid memory of reading the Aurora docs and seeing the same limit. Oh well, it's something to consider for the next upgr…

  12. comment
    Comment #25911075

    basically what paulryanrogers said. We thought about migrating to Citus, but I don't have a good idea of how to shard our dataset efficiently. If we were to shard by user id, then …

  13. comment
    Comment #25910988

    ants_a is correct. Also, our NVMe storage is ephemeral so you aren't recovering from a power loss anyways :)

  14. comment
    Comment #25910841

    How would that have worked with multiple replicas cascading from the new primary? Streaming replication doesn't work across versions, so would we have had to build out a tree of ne…

  15. comment
    Comment #25910593

    Thanks! We stuck with plain EC2. RDS has a limit of 80,000 provisioned IOPS and our read replicas on Postgres 9.6 would regularly hit near double that during peak

  16. story