{"push_id":2492778607,"size":1,"distinct_size":1,"ref":"refs/heads/plan_expand_hypertables","head":"4c129524ea9b558459b78619f22f41ba2690e7fc","before":"e072f9441ac0f78b0eec26b4b1872235af33cb9f","commits":[{"sha":"4c129524ea9b558459b78619f22f41ba2690e7fc","author":{"name":"Matvey Arye","email":"cc7c5be316e48d137cbb549833b85d91034d799d@timescale.com"},"message":"Optimize planning times when hypertables have many chunks\n\nThis planner optimization reduces planning times when a hypertable has many chunks.\nIt does this by expanding hypertable chunks manually, eliding the `expand_inherited_tables`\nlogic used by PG.\n\nSlow planning time were previously seen because `expand_inherited_tables` expands all chunks of\na hypertable, without regard to constraints present in the query. Then, `get_relation_info` is\nthe called on all chunks before constraint exclusion. Getting the statistics an many chunks ends\nup being expensive because RelationGetNumberOfBlocks has to open the file for each relation.\nThis gets even worse under high concurrency.\n\nThis logic solves this by expanding only the chunks needed to fulfil the query instead of all chunks.\nIn effect, it moves chunk exclusion up in the planning process. But, we actually don't use constraint\nexclusion here, but rather a variant of range exclusion implemented\nby HypertableRestrictInfo.","distinct":true,"url":"https://api.github.com/repos/timescale/timescaledb/commits/4c129524ea9b558459b78619f22f41ba2690e7fc"}]}
{"actor":{"display_login":"cevian"}}