> On 30-06-2021, at 16:56, Manuel Weitzman <manuelweitzman@xxxxxxxxx> wrote: > > One way in which I see possible to share this kind of information (of > extremal values) across RestrictInfos is to store the known variable > ranges in PlannerInfo (or within a member of such struct), which seems > to be around everywhere it would be needed. I have written a new patch that's (hopefully) better than the first one I sent, to store the extremal index values within PlannerInfo. > it is also possible to reproduce the increasing cost in planning > buffers for each new join on a distinct table being added: > > [...] > > I can imagine that deconstruct_jointree() and > generate_join_implied_equalities() would generate multiple > RestrictInfos, in which many of them a constraint on a.a would be > involved (each involving a different table). I also attached an example in which there are RestrictInfos generated for multiple tables instead of just a single aliased one. The buffers read for planning also increase with each join added to the query. Best regards, Manuel
Attachment:
actual_variable_range_cache.patch
Description: Binary data
Attachment:
planning_buffers.sql
Description: Binary data
