[PERFORM] Another parallel postgres project...

I previously posted about par_psql, but I recently found another PG parallelism project which can do a few extra things that par_psql can’t: https://github.com/moat/pmpp pmpp: Poor Man's Parallel Processing. Corey Huinker had the idea of using dblink async as a foundation for distributing

Re: [PERFORM] Another parallel postgres project...

Thanks for the shout-out. This is the project that I presented at PgConfUS 2015. It took a while for Moat's (http://moat.com) lawyers to come around to licensing the code, but they finally did. On Tue, Sep 29, 2015 at 4:41 AM, Graeme B. Bell wrote: > I previously posted

Re: [PERFORM] Performance problem with gin index

Thx you for your hints. I found lot of information in this thread http://postgresql.nabble.com/how-to-investigate-GIN-fast-updates-and-cleanup-cycles-td5863756.html Currently, we are monitoring pending_pages (pgstatginindex works on 9.4.4), and run a vacuum every night. We hope it will solve the

[PERFORM] dump restoration performance

Please how long does it take approximately to restore a 300 Go database using pg_restore ? Are there benchmarks for that ? -- View this message in context: http://postgresql.nabble.com/dump-restoration-performance-tp5867370.html Sent from the PostgreSQL - performance mailing list archive at

Re: [PERFORM] dump restoration performance

On Fri, Sep 25, 2015 at 10:43 PM, rlemaroi wrote: > Please how long does it take approximately to restore a 300 Go database using > pg_restore ? Are there benchmarks for that ? That's not an exact science and this is really application-dependent. For example the

Re: [PERFORM] Performance problem with gin index

On Tue, Sep 29, 2015 at 8:45 AM, Bertrand Paquet < bertrand.paq...@doctolib.fr> wrote: > Hi, > > We have got big slow down on our production plateform (PG 9.4.4). > What is it slow compared to? Did your version change, or your workload/usage change? > > After analyzing wals with pg_xlogdump,