3 ms·

Implemented especially for cab companies to use Postgres as key-value store.

• lucian1900 10y ago
  Not really. Another similar use-case is game sessions. Membership within a session changes constantly and so do the sessions themselves. They are also both deleted often. If you run pg_dump on the same instance, it will keep long transactions open, which will cause VACUUM to struggle.
  • ahachete 10y ago
    That's true, but why would you want to run pg_dump on the instance? Use pg_receivexlog and friends to have a physical backup and pg_recvlogical for logical backups and you avoid the problem with pg_dump (you're alone with other long-running tx, but it may help).
    • koolba 10y ago
      Regardless of other forms of backups it's useful to have a logical pg_dump based one as well. When shit hits the proverbial fan its nice to have a totally separate backup path that, even if it's not as up to date as a streaming physical backup, can be easily restored. Biggest issues I've heard are either the long running transaction (mitigated a bit by running on a slave), cache busting effect (reading all your data thrashes your OS disk cache), and how painfully long it can take (good luck running pg_dump on a multi TB database). As a backup to a more "live" backup, it's nice to have though. Plus it's dead simple to restore a DB via pg_restore in a lower environment for testing.
      • ahachete 10y ago
        Size does matter. And there are databases which you practically can't backup logically (as you mentioned). So IMHO only applies to small databases in which case, sure, a pg_dump is always handy. But not in the rest of the cases.