A Timeseries Case Study: InfluxDB VS PostgreSQL
Hi, I recently published a blog article reporting a small research I made on the usage of InfluxDB and PostgreSQL for time series, together with Grafana on my specific use case. I think that some of you might find it interesting, maybe inspiring or perhaps it can trigger some interesting discussion, given the high level of expertise of people in this mailing list. I reached out to InfluxDB guys, but after an initial ack, I did not hear from them any longer. https://portavita.github.io/2018-07-31-blog_influxdb_vs_postgresql All comments, critics, suggestions and corrections are very welcome Regards, fabio pardi
Re: bad url in docs
On Thu, Sep 06, 2018 at 04:57:17PM -0600, Rob Sargent wrote: > Sorry. I didn't see the specific form for documentations issues. There is a link [1] on bottom of the documentation page [2] to the report form. It is in the "Submit correction" section. A documentation issue is sent to pgsql-docs mailing list. 1 - https://www.postgresql.org/account/comments/new/10/libpq-ssl.html/ 2 - https://www.postgresql.org/docs/10/static/libpq-ssl.html -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
Re: A Timeseries Case Study: InfluxDB VS PostgreSQL
On 07/09/2018 11:07, Fabio Pardi wrote: Hi, I recently published a blog article reporting a small research I made on the usage of InfluxDB and PostgreSQL for time series, together with Grafana on my specific use case. I think that some of you might find it interesting, maybe inspiring or perhaps it can trigger some interesting discussion, given the high level of expertise of people in this mailing list. I reached out to InfluxDB guys, but after an initial ack, I did not hear from them any longer. https://portavita.github.io/2018-07-31-blog_influxdb_vs_postgresql All comments, critics, suggestions and corrections are very welcome Nice read! Wonder if you could repeat the tests on pgsql 10.5 and btree/BRIN. Regards, fabio pardi -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt
Re: A Timeseries Case Study: InfluxDB VS PostgreSQL
Hi Achilleas, I'm glad you like the article. Probably I will find the time to come back to the topic when I'm done comparing Mongodb with PostgreSQL regards, fabio pardi On 07/09/18 11:18, Achilleas Mantzios wrote: > Nice read! Wonder if you could repeat the tests on pgsql 10.5 and btree/BRIN.
connection error
getting below error from application side : Last acquisition attempt exception: org.postgresql.util.PSQLException: Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. the port no is set correct : [postgres@lxsqlptgsdev004 data]$ psql -h localhost -p 5432 psql (9.5.14) Type "help" for help. postgres=# In pg_hba.conf also: # IPv4 local connections: hostall all 127.0.0.1/32trust hostall all 127.0.0.1/23trust hostall all 172.29.161.53/23trust hostall all 172.29.161.52/23trust Can someone please help what can be done to resolve this. Thanks, Sonam
Re: A Timeseries Case Study: InfluxDB VS PostgreSQL
Fabio Pardi schrieb am 07.09.2018 um 10:07: > Hi, > I recently published a blog article reporting a small research I made on > the usage of InfluxDB and PostgreSQL for time series, together with > Grafana on my specific use case. > > I think that some of you might find it interesting, maybe inspiring or > perhaps it can trigger some interesting discussion, given the high level > of expertise of people in this mailing list. > > I reached out to InfluxDB guys, but after an initial ack, I did not hear > from them any longer. > > https://portavita.github.io/2018-07-31-blog_influxdb_vs_postgresql > > All comments, critics, suggestions and corrections are very welcome Did you ever look at Timescale? https://www.timescale.com/ It's implemented as a Postgres extension. Would be interesting to compare with a "native" time series database
Re: A Timeseries Case Study: InfluxDB VS PostgreSQL
Interesting and useful article, Fabio. I'm actually quite curious about your evaluation of MongoDB & Postgres. I've been operating under the opinion that MongoDB has been obsoleted in every respect by Postgres and am curious as to whether there are any credible use cases where, given the opportunity to choose from the beginning which technology to build a new product on, I would ever select MongoDB over Postgres given the choice between them. best regards, - - Ben Scherrey On Fri, Sep 7, 2018, 5:16 PM Fabio Pardi wrote: > Hi Achilleas, > > I'm glad you like the article. > > Probably I will find the time to come back to the topic when I'm done > comparing Mongodb with PostgreSQL > > regards, > > fabio pardi > > > On 07/09/18 11:18, Achilleas Mantzios wrote: > > Nice read! Wonder if you could repeat the tests on pgsql 10.5 and > btree/BRIN. > > >
Re: connection error
Do you have following entry as well? # IPv6 local connections: hostall all ::1/128 trust I hope "listen_addresses " in postgresql.conf is on default setting. Regards, Amul Sul On Fri, Sep 7, 2018 at 4:08 PM Sonam Sharma wrote: > > getting below error from application side : > > > Last acquisition attempt exception: > > org.postgresql.util.PSQLException: Connection refused. Check that the > hostname and port are correct and that the postmaster is accepting TCP/IP > connections. > > > the port no is set correct : > > [postgres@lxsqlptgsdev004 data]$ psql -h localhost -p 5432 > > psql (9.5.14) > > Type "help" for help. > > > > postgres=# > > In pg_hba.conf also: > > > # IPv4 local connections: > > hostall all 127.0.0.1/32trust > > hostall all 127.0.0.1/23trust > > hostall all 172.29.161.53/23trust > > hostall all 172.29.161.52/23trust > > > Can someone please help what can be done to resolve this. > > > Thanks, > > Sonam
Re: connection error
On Fri, Sep 7, 2018 at 5:10 PM amul sul wrote: > > Do you have following entry as well? > > # IPv6 local connections: > hostall all ::1/128 trust > > I hope "listen_addresses " in postgresql.conf is on default setting. > Sorry, I misread -- your local psql connection is fine . Try setting listen_addresses = '*' in postgresql.conf. For more detail please have a look to https://www.postgresql.org/docs/9.5/static/runtime-config-connection.html Regards, Amul Sul
Re: A Timeseries Case Study: InfluxDB VS PostgreSQL
Hi All, Full disclosure: I'm a Timescale employee. Fabio, really interesting analysis and we can generally confirm the conclusions of your tests. As Thomas pointed out above, TimescaleDB is an open-source time-series database packaged as Postgres extension. We are always interested in performance comparisons between TimescaleDB and vanilla Postgres and have run a few ourselves (compared to 9.6 and insert rates/ease-of-use in PG10). We'll of course be looking at comparisons to PG11 and where improvements in PG11 also carry over to TimescaleDB. Third-party comparisons are also welcome, especially from someone well-acquainted with Postgres. We have also run benchmarks comparing TimescaleDB and MongoDB that might be useful/interesting for folks here: https://blog.timescale.com/how-to-store-time-series-data-mongodb-vs-timescaledb-postgresql-a73939734016 And in reference to the earlier discussion of InfluxDB, here's a similar post comparing TimescaleDB with InfluxDB: https://blog.timescale.com/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877 Finally, if you're interested, here's the open source tool we use to run our database comparison benchmarks: https://github.com/timescale/tsbs Let me know if you have any TimescaleDB specific questions! On Fri, Sep 7, 2018 4:08 AM, Benjamin Scherrey scher...@proteus-tech.com wrote: Interesting and useful article, Fabio. I'm actually quite curious about your evaluation of MongoDB & Postgres. I've been operating under the opinion that MongoDB has been obsoleted in every respect by Postgres and am curious as to whether there are any credible use cases where, given the opportunity to choose from the beginning which technology to build a new product on, I would ever select MongoDB over Postgres given the choice between them. best regards, - - Ben Scherrey On Fri, Sep 7, 2018, 5:16 PM Fabio Pardi wrote: Hi Achilleas, I'm glad you like the article. Probably I will find the time to come back to the topic when I'm done comparing Mongodb with PostgreSQL regards, fabio pardi On 07/09/18 11:18, Achilleas Mantzios wrote: > Nice read! Wonder if you could repeat the tests on pgsql 10.5 and btree/BRIN. TimescaleDB | Head of Marketing & Communityc: 908.581.9509 335 Madison Ave.New York, NY 10017http://www.timescale.com/ https://github.com/timescale/timescaledb
Re: pgbackrest when data/base is symlinked to another volume
Hi Ron, On 9/6/18 11:21 PM, Ron wrote: Will pgbackrest properly backup and restore the cluster if data/base, data/pg_xlog and data/pg_log are symlinks? PGDATA=/var/lib/pgsql/9.6/data $PGDATA/base -> /Database/9.6/base $PGDATA/pg_log -> /Database/9.6/pg_log $PGDATA/pg_xlog -> /Database/9.6/pg_xlog Yes, this will work. Note that restore does not recreate symlinks by default so you'll need to specify --link-all to enable symlink creation. See https://pgbackrest.org/configuration.html#section-restore/option-link-all for details. Using symlinks in this way will make management of your clusters more difficult, mostly because systems need more provisioning before restores can be performed. In general I'd recommend against it unless there are performance considerations. Also, you might consider using log_directory to relocate log files rather than a symlink. This will exclude log files from your backup which is usually preferable -- primary logs restored to a standby are out of context and can cause confusion. Regards, -- -David da...@pgmasters.net
Re: pgbackrest when data/base is symlinked to another volume
On 09/07/2018 05:22 PM, David Steele wrote: Hi Ron, On 9/6/18 11:21 PM, Ron wrote: Will pgbackrest properly backup and restore the cluster if data/base, data/pg_xlog and data/pg_log are symlinks? PGDATA=/var/lib/pgsql/9.6/data $PGDATA/base -> /Database/9.6/base $PGDATA/pg_log -> /Database/9.6/pg_log $PGDATA/pg_xlog -> /Database/9.6/pg_xlog Yes, this will work. Note that restore does not recreate symlinks by default so you'll need to specify --link-all to enable symlink creation. See https://pgbackrest.org/configuration.html#section-restore/option-link-all for details. Using symlinks in this way will make management of your clusters more difficult, mostly because systems need more provisioning before restores can be performed. In general I'd recommend against it unless there are performance considerations. Also, you might consider using log_directory to relocate log files rather than a symlink. This will exclude log files from your backup which is usually preferable -- primary logs restored to a standby are out of context and can cause confusion. Thanks for the tips. I'll probably implement that on our new systems. -- Angular momentum makes the world go 'round.
Re: pgbackrest when data/base is symlinked to another volume
On 09/07/2018 05:22 PM, David Steele wrote: Hi Ron, On 9/6/18 11:21 PM, Ron wrote: Will pgbackrest properly backup and restore the cluster if data/base, data/pg_xlog and data/pg_log are symlinks? PGDATA=/var/lib/pgsql/9.6/data $PGDATA/base -> /Database/9.6/base $PGDATA/pg_log -> /Database/9.6/pg_log $PGDATA/pg_xlog -> /Database/9.6/pg_xlog Yes, this will work. Note that restore does not recreate symlinks by default so you'll need to specify --link-all to enable symlink creation. See https://pgbackrest.org/configuration.html#section-restore/option-link-all for details. Using symlinks in this way will make management of your clusters more difficult, mostly because systems need more provisioning before restores can be performed. In general I'd recommend against it unless there are performance considerations. Now that I'm thinking more about what you wrote... "data" isn't on it's own partition. data/*base* has it's own partition. What's the recommended method for putting *base**/* on a partition different from data/? Or is that not recommended? -- Angular momentum makes the world go 'round.
