2018-01-09 18:15 GMT+01:00 Andrew Staller <and...@timescale.com>: > This is the blog post that Rakesh referenced: > https://blog.timescale.com/time-series-data-postgresql- > 10-vs-timescaledb-816ee808bac5 > > Please note, this analysis is done in the context of working with > time-series data, where 1000s of chunks is not uncommon because of the > append-mostly nature of the workload. > > On Mon, Jan 8, 2018 at 6:54 PM, Rakesh Kumar <rakeshkumar...@mail.com> > wrote: > >> >> You should have read carefully what I wrote. 1000 is not an upper >> limit. 1000 partition is the number after which performance starts >> dropping . >> >> There is a blog in www.timescale.com which also highlights the same. >> >> Sent: Monday, January 08, 2018 at 6:20 PM >> From: "Kumar, Virendra" <virendra.ku...@guycarp.com> >> To: "pgsql-gene...@postgresql.org" <pgsql-gene...@postgresql.org> >> Subject: How Many Partitions are Good Performing >> >> Can somebody tell us how many partitions are good number without >> impacting the performance. We are hearing around a thousand, is that a >> limit. Do we have plan to increase the number of partitions for a table. We >> would appreciate if somebody can help us with this? >> >> Regards, >> Virendra >> >> >> ------------------------------------------------------------ >> This message is intended only for the use of the addressee and may contain >> information that is PRIVILEGED AND CONFIDENTIAL. >> >> If you are not the intended recipient, you are hereby notified that any >> dissemination of this communication is strictly prohibited. If you have >> received this communication in error, please erase all copies of the >> message >> and its attachments and notify the sender immediately. Thank you. >> >> > > > -- > TimescaleDB* | *Growth & Developer Evangelism > c: 908.581.9509 > > 335 Madison Ave. > <https://maps.google.com/?q=335+Madison+Ave.%C2%A0New+York,+NY%C2%A010017&entry=gmail&source=g> > New York, NY 10017 > <https://maps.google.com/?q=335+Madison+Ave.%C2%A0New+York,+NY%C2%A010017&entry=gmail&source=g> > http://www.timescale.com/ > https://github.com/timescale/timescaledb >
The data about the query performances would have shed more light on the situation. Unluckily there's none. Weird! -- Vincenzo Romano - NotOrAnd.IT Information Technologies -- NON QVIETIS MARIBVS NAVTA PERITVS
