My fear, when we introduced hints, was that there would be many cases where people would hope that rules propagate hints and the rules do not; and that in some cases, the expected behavior isn't even clear.
Maybe this can be addressed by the power of open source: people find an issue, submit a patch. But maybe not: people will discover that most of the time, the hints they expected just aren't there. We'll see. It depends on the proportion of people who find broken stuff and fixing vs people who find broken stuff and walk away shaking their head. In this case, a pragmatic solution might be to convert the hint to a query-level hint. Hints that apply to the whole query are not going to be lost when rules are fired. On Wed, May 26, 2021 at 2:05 PM Stamatis Zampetakis <[email protected]> wrote: > > Hi Taras, > > I haven't used hints much but what you describe sounds like a bug. > > I would expect that rules should preserve hints if possible. I guess that > if a rule removes an operator completely then it may not make sense to > retain the hints. > > Best, > Stamatis > > On Wed, May 26, 2021, 1:26 PM Taras Ledkov <[email protected]> wrote: > > > Hi, > > > > I am trying to figure out how to use hints correctly. > > > > My case: > > I've registered hint for Aggregate node to force expand DISTINCT aggregate. > > Because is some cases plan with DISTINCT aggregate to JOIN cannot be > > chosen by the cost. > > > > I see that different rules treat hints differently. > > e.g.: > > - AggregateExpandDistinctAggregatesRule - copy hints of the source node > > for new aggregate nodes. > > - AggregateReduceFunctionsRule - create new node and looses the original > > hints. > > > > Is is correct behavior and am I missing something at the hints/planner > > logic? > > > > -- > > Taras Ledkov > > Mail-To: [email protected] > > > >
